Cart
[Home] [By Thread] [By Date] [Recent Entries]
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 Stefan -- SAX-based access to WBXML and WML: http://www.trantor.de/wbxml XML pull parser: http://www.trantor.de/xml
|
