Then Bohr said, I think this is divisible, further
Even an atomic RDC is made of mulitple artifacts. Usually, an atomic RDC is the combination of:
A tag file - This is the implementation of the JSP tag that corresponds to this component. All components are implemented as JSP 2.0 tag files, which in addition to allowing the same programming model for authoring and instantiation, also facilitates composition.
A private data model - The private data model defines how the component processes user input. It contains crucial information about canonicalization and validation of user input. It is also used to persist component state across multiple requests.
A speech grammar - This defines the set of valid utterances that a user may respond with when prompted for input by this component. There may be more than one grammar files (speech and DTMF) that contribute to the component grammar.
A configuration file - Each atomic RDC comes with a default configuration file. It is clear that the prompts contained in this configuration file are almost guaranteed to be replaced in each instance while authoring an application, since the author will want to use prompts that fit with the given application and task being performed. For example, a default prompt of Please specify a date may be replaced by Please specify the departure date when collecting a departure date in a travel application. The default configuration is overridden by providing a new configuration file that is passed to the component via its config tag attribute.
A public data model (optional) - This establishes the type of the return value that the application should expect from this component. There is no need to define a public data model if the component returns say, a java.lang.String or java.util.Date object.
All of these artifacts expect the others to fulfill their internal contracts for a component to function. Thus, replacing one of these will very often require changes to (some or all of) the others.