Lists Home |
Date Index |
- From: Stefan Haustein <email@example.com>
- To: firstname.lastname@example.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...
SAX-based access to WBXML and WML: http://www.trantor.de/wbxml
XML pull parser: http://www.trantor.de/xml