Re: extensibility in XSchema?
Simon St. Laurent wrote: > The contents of this metadata need to be standardized as well. XML-Data could > provide a start for this. I think it goes beyond the limited tasks we've set > ourselves, though it is certainly key to providing the functionality which > many people on this list clearly want. This could be XSchema 2.0, or we could > attempt to do it in 1.0, or it could be a separate spec. This is clearly a 2.0 issue. Let's get 1.0 out the door, but make sure there's room for extensions. I also think that Paul's XSL-style rule model has a place. The more I think about it, the more I am convinced that this is the way to go for reusability and possibility for extensibility. Is there a way we can allow this by moving attribute definitions outside of elements and simply allowing multiple element definitions? While we would allow only one content model, future constraints, such as data types, range restrictions, etc. could easily reside in multiple declarations: <ElementDecl Name="MyElement"> <PCData/> </ElementDecl> <ElementDecl Name="MyElement"> pointer to data type, range restriction, etc. in another XSchema file </ElementDecl> I am still not convinced about pattern-matching, though. Although I can see some utility in saying, for example, that when a date is in a title, it must fall in a certain range, I am not comfortable with the stability of XSL patterns (see Paul Grosso's message of 24 June) or the wealth of possible implementation and specification problems. (This could be simply my ignorance.) > XSchemas had been moving in a direction where simple validation was enough to > make sure the XSchema was properly structured. This is getting in the way of > several suggestions that could potentially improve XSchema, for instance Chris > Maden's reduction of the empty elements in the notation and attribute > declarations to attributes. The tasks that have been proposed for XSchema > processors are not very complex and provide significant improvements in > XSchema readability and authorability. I'm leaning more and more toward > giving XSchema processors a bit more work to do. I think XSchema processors are simply going to have to do more checking than we had originally thought. Given that this is so, let's keep the syntax clean and put a little more burden on the processor writers to make users' lives easier. By the way, I'm currently writing an XSchema-to-DTD processor built on top of SAX (first version available tomorrow if I figure out namespaces), but my next project will be an XSchema conformance checker also built on SAX. Assuming this code also generates SAX events, it can be easily be reused by others, so conformance becomes even less of a problem. -- Ron Bourret xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format