OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

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

[ Lists Home | Date Index | Thread Index ]
  • From: Jonathan Borden <jborden@mediaone.net>
  • To: keshlam@us.ibm.com
  • Date: Mon, 07 Aug 2000 11:09:20 -0400

keshlam@us.ibm.com 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





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS