[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Arbitrary Infoset boundaries (was Re: Common XML - Final

• From: Jonathan Borden <jborden@m...>
• To: keshlam@u...
• Date: Mon, 07 Aug 2000 11:09:20 -0400

keshlam@u... wrote:
>
> >But if DOM L3 will be based upon the Infoset, and the Infoset doesn't
> >contain DTDs then how will that work?
>
> The Infoset spec explicitly says that there's no reason something which
> conforms to the Infoset need _only_ carry the data in the Infoset. We can
> easily supply more details than are required (and we already do, in some
> cases).
>
> I'd much rather have the Infoset lead the way here -- in my opinion, the
> DOM should primarily be an API to the Infoset, and the Infoset should
> included all the information derivable directly from the XML document,
> including its DTD and Schema(s) if applicable. But if Infoset
> doesn't blaze
> this path, the DOM must.

	Right. This is the reason I favor a "full fidelity" infoset which can be
"dumbed down" or subsetted to an arbitrary level. It has been suggested that
this would be too difficult, too time consuming, and that this might not be
an appropriate activity for the W3C. In fact, over the weekend, I've
completed the first cut at an XML'ization of the XML 1.0 *and* XML
Namespaces production set, which I call XSet. It is available at:
http://www.openhealth.org/XSet/xml.xml. What is missing are the full set of
WFC,VC, and NSC constraint definitions. My idea was to use XPath to specify
these ala Schematron, though I may need to bone up on some advanced XPath,
e.g. how does one specify that a PEReference if defined in the internal
subset may only be at the top level. Ideas?

	The reason that XPath can be used is that this description is essentially
an XML expansion of an XML document (a similar process can thus be used for
the DOM): e.g.


/document/element[Name='example']/element[Name='whatever']/STag/Attribute[3]
/Name

	= "ok" given the document:

	<example>
		<whatever yeah="1" its="22" ok="xyz">
			...
		</whatever>
	</example>

	and


/document/element[Name='example']/element[Name='whatever']/STag/Attribute[Na
me="ok"]/AttValue/c[3] = 'y'

	matches the third character of the attribute value, (the first character is
")

	This production language is a type of schema description language. It has
the property of being both understandable and reasonably terse for human
consumption. The productions from XML 1.0 and XML Names are in two distinct
rdf:Descriptions, I need to specify that XML Names both inherits from and
overrides productions of the same name in XML 1.0.

	The point being that development of XSet based upon XML1.0 and XML Names
was so straightforward for the specific reason that both are specified using
normative formal definitions. The fact that this could be so readily done is
a tribute to the XML 1.0 spec itself.

Jonathan Borden
The Open Healthcare Group
http://www.openhealth.org

• Follow-Ups:
  • XSet: an example of how to derive an API
    • From: Jonathan Borden <jborden@m...>

• References:
  • RE: Arbitrary Infoset boundaries (was Re: Common XML - Final
    • From: keshlam@u...

• Prev by Date: Re: System identifiers and base URIs
• Next by Date: XSet: an example of how to derive an API
• Previous by thread: RE: Arbitrary Infoset boundaries (was Re: Common XML - Final
• Next by thread: XSet: an example of how to derive an API
• Index(es):
  • Date
  • Thread