Milton,
You just produce a NAS specific DD which is added to the same directory
in the jar as the standard DD. The NAS DD contains whatever info it
needs to and if it wants to 'link' that info to an element in the
standard DD it puts the ID value of the standard element into the
content of the NAS element. Since both documents are in the same
directory it is easy to define a convention for how 'links' are stored
in the NAS document. Since only NAS specific tools will ever look at the
NAS DD, they will be able to understand and evaluate these 'links'.
This informal mechanism is all that's needed.
-- Mark
Milton Soong wrote:
>
> I am staring at the EJB1.1 Public draft 3, and on page 259 the spec mentioned that:
>
> "The ID mechanism is to allow tools that produce additional deployment information
>(i.e information beyond the stardard EJB deployment descriptor information) to store
>the non-standard
> information in a separate file, and easily refer from these tools-specific files to
>the information in the standard deployment descriptor."
>
> Can someone give me more details on how this "...easily refer from these
>tools-specific files" is done? A quick look through a few XML books are all vague on
>this. The formal XML way to
> refer to an unparsed entity (or a parsed entity for that matter if these tool
>specific files are also in XML format) requires more tags than just a simple ID.
>
> Milton Soong
> Sun-Netscape Alliance
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
