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