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


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: Schema concepts (was Re: W3C public lists (was Re: The Power of Grov

[ Lists Home | Date Index | Thread Index ]
  • From: Stefan Haustein <stefan.haustein@trantor.de>
  • To: xml-dev@xml.org
  • Date: Sat, 12 Feb 2000 20:37:06 +0100

Matthew Fuchs wrote:
> I've consoled myself by realizing it's not hard to specify a <metatype>
> which unifies both <element> and <type> and therefore leaves open the
> possibility of evolving to non-Euclidean markup in the future.

That brings me to an idea. I could just convert all named types to 
abstract elements with a hash sign in front during schema parsing.
Furthermore, I could insert "pcdata" nodes in the memory data 
structure to get rid of the concept of "content type". If I 
eliminate all the strange concepts during parsing, I do not need to 
struggle around with them later when doing something "real" with
the parsed schema....

> The XML Schema language will soon be moving to Candidate Recommendation
> status (we hope).  During that time we will be looking for implementation
> feedback.  If your experience shows that the type system enforced by the
> current language is ill-fitted to your requirements, make that known.  CR is
> when you get to show we're wrong.

It's not that it is not possible to use it. But it makes everything
more complicated than needed, at least if the API is close to the
schema syntax. You always need an extra indirection level in order 
to access the type information of an element. You also need additional
consistency checks for overlapping concepts like content-type vs. type... 

Best regards


SAX-based access to WBXML and WML: http://www.trantor.de/wbxml
XML pull parser: http://www.trantor.de/xml


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

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