LC-82 XML Schema considered inadequately extensible

The Schema WG has asked me to respond to Robert Miller's discussion of 
extensibility, found in
http://lists.w3.org/Archives/Public/www-xml-schema-comments/2000AprJun/0120.html. 
This
response represents my opinion, and will be taken as further feedback on 
the topic by the Working Group.

On Tue, 2 May 2000 15:43:11 -0400, Robert Miller <Robert.Miller@gxs.ge.com> 
wrote:

>I suppose my greatest concern is that the capabilities represented in the 
>Schema work are not further extendible without also extending the Schema 
>syntax. That's a steep hill for proposed new extensions to climb, and will 
>likely act as a squelch on such extensions. As one who sees shortcomings 
>in what is supported in the current Schema work, I find the closed Schema 
>syntax disturbing.
>Amid the complexity of the Schema specification is some much wished for 
>capability, and I've been among those making wishes, as the DTD capability 
>provides little of what is needed for Business Information Exchange. But 
>as much as I want such capability, I fear that Schema is all we'll get, it 
>won't be enough, and we'll have to pass it by for something better. That 
>would be disheartening.
>A design more in keeping with my desires for extensibility would define a 
>syntax by which active service packages could be associated with XML 
>elements. Edit constraints might be one such service, and one which might 
>(and should) be pre-defined for use. The addition of new services would 
>not require a change to the XML Schema syntax, it would simply require the 
>definition of the new service and access to the process(es) supporting the 
>extended service.

I agree with the need for extensibility mechanisms for XML schemas, and I 
need - and use - extensibility mechanisms myself. However, I see advantages 
to systems such as Extensibility's Schema Adjunct Framework [1], which 
allow extensibility for any schema dialect, and are not dependent on any 
particular external environment. For instance, my company makes a native 
XML database, and we use the Schema Adjunct Framework to define indexing 
parameters and component levels using XDR, and will do the same for XML Schema.

Several companies are currently writing software that uses such 
extensibility mechanisms to allow their software to interoperate using 
extensions of existing schema languages, but I would say that such work is 
in early stages.

It is not clear to me that such extensibility mechanisms should be embedded 
in a given schema, since the extensions may need to be separated from the 
schema itself. For instance, a given schema might be indexed differently 
for different uses in different databases, e.g. with fine granularity for 
editing, but coarse granularity for publishing.

In my opinion, extensibility mechanisms are vital. They should be extremely 
general,  not tied to any particular environment, and preferably not tied 
to a given schema language, since at least DTDs and XML Schema are liable 
to be important to the future of XML. (Some members of the Working Group 
may disagree with me about DTDs, but I believe that a simple schema 
language will continue to be desirable for many purposes.) They also should 
be capable of being expressed externally to a given schema.

If the Schema Adjunct Framework [1] is not what you want, I encourage you 
to experiment with other approaches. If you wish to embed your extensions 
into a schema, you may consider using Appinfo to do that.

In my opinion, adding support for one limited form of extensibility to XML 
Schema at this point might actually hinder development of more general 
extensibility mechanisms, and since several vendors are experimenting with 
at least one form of extensibility mechanism right now, I would like to see 
the industry gain a little more experience with this approach before 
attempting to standardize it.

Please feel free to respond to this, pointing out things I may have missed 
or misunderstood.

Jonathan

[1] http://www.extensibility.com/saf/index.htm

Received on Thursday, 8 June 2000 11:48:08 UTC