I don't see why there can't be a DTD or equivalent that covers all the
possibilities available for the most inclusive distribution at the time
of the release. Those who lack some modules won't be interested in what
they've elected not to have anyway. Add-on modules that add to
domain.xml should provide documentation of the additions. Why can't
this be done?
If GlassFish Engineering insists that a definitive DTD is not possible,
then I don't see any point in publishing a book on the domain.xml file.
There's no way I can get reliable information, therefore I can't write
the book with any certainty of its accuracy. I've tried to make do with
scraps of information, but it looks like what I need to do an adequate
job is not forthcoming.
If Engineering is developing some kind of configuration extraction
process with @Documentation annotations, or whatever form user-readable
comments take, great, I'm willing to help edit those comments. As for
documenting domain.xml in book form, as I have done for several releases
now, I don't think I can continue under these circumstances.
June
On 06/23/09 12:24, Tim Quinn wrote:
> Vince Kraemer wrote:
>> Tim Quinn wrote:
>>> From time to time there have been requests for DTDs or XSDs for the
>>> v3 domain.xml. But because the content of domain.xml is variable,
>>> depending on what modules are installed, this is not really feasible.
>>
>> Since xml means eXtensible Markup Language, if have to wonder why you
>> say this..
>>
>> It seems like we should be able to use schemas to create a complex,
>> dynamic document that can be more validated than, "Is this document
>> well-formed?"
>>
>> What is the impediment that makes it not really feasible?
> My point - poorly-stated, perhaps - is that we cannot publish a single
> authoritative and complete DTD or XSD on, say, a Glassfish web site,
> that will apply to all GlassFish installations, nor can we ship such a
> thing for installation with GlassFish itself. Different GlassFish
> installations will (eventually) include different combinations of
> modules depending on what types of apps those users want to support,
> and even that set can change over time for a single installation.
> The acceptable contents of the domain.xml file can therefore be
> different for different installations of GlassFish. Hence a single,
> installed or centrally-published DTD or XSD does not suffice.
> That's all I meant.
> As for validation, in practice the GlassFish configuration subsystem
> does "validate" the domain.xml when it loads the configuration into
> memory during start-up. The elements in the XML file correspond
> directly to Java interfaces marked with the @Configured annotation.
> Each interface's methods, annotated with @Attribute or @Element,
> define the corresponding element's attributes and subelements that
> will be permitted in the XML. The config subsystem will complain when
> it finds an XML element, subelement, or attribute that the interface
> definitions do not declare. It's not validation against an XSD, but
> it is validation in a different sense.
> - Tim
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>