xml-dev - Re: extensibility in XSchema?

[rbourret@dvs1.informatik.tu-darmstadt.de (Ron Bourret)]

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@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)