extensibility in XSchema?
rbourret at dvs1.informatik.tu-darmstadt.de
Tue Jun 30 20:11:48 BST 1998
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
pointer to data type, range restriction, etc. in another XSchema file
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 at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
More information about the Xml-dev