OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: extensibility in XSchema?

[ Lists Home | Date Index | Thread Index ]
  • From: rbourret@dvs1.informatik.tu-darmstadt.de (Ron Bourret)
  • To: xml-dev@ic.ac.uk
  • Date: Fri, 26 Jun 1998 09:50:58 +0200

John Cowan wrote:

> Doc was definitely intended for documentation only.  I have thoughts
> on extensibility, but no time to write them up today: hopefully
> tomorrow.

I'm looking forward to hearing your ideas.  Extensibility is my greatest area of 
concern in XSchema and, although I've got some ideas, none are wholly 
satisfying.

As I understand it, our current plan for extensibility is that new types of 
constraints (such as data types) can be added to ElementDecl and AttDef as 
standard, optional elements in future versions of XSchema.  The standardization 
of such elements is rather critical, as the whole point is to make sure that 
everybody is playing the same game -- without standardization, we will be back 
to where we are today.

(For backwards compatibility, note that a 1.0 document will continue to validate 
against later DTDs because the new subelements are optional.  And a later 
document will validate against a 1.0 application as long as it doesn't use any 
of the new subelements. This is how backwards compatibility is done in the code 
world, and seems reasonable to me.  If we want better forward compatibility, we 
can state that XSchema applications should assume that any elements they don't 
recognize are from a future version and should be discarded.)

However, I keep having a recurring vision of people being able to add their own 
metadata in addition to that which the spec defines and being able to do this 
without changing the DTD -- the same thing that Mark Anderson recently asked 
for.  At first, I thought that Paul Prescod's pattern/constraint model would 
magically solve this problem, but after further research, realized that its 
extensibility is almost certainly no different than the current model's -- new, 
optional constraints are added to the DTD over time.

The only way I can think of to do this is less than elegant and matches Simon's 
suggestion (a):  Add a UserSpecific subelement (frequency = *) to the end of the 
content models for ElementDecl and AttDef.

-- If UserSpecific has a content model of ANY, people can then invent their own 
elements.  The resulting file is not valid, but will be well-formed.  We would 
also need to state that applications that check the XSchema itself would ignore 
the children of UserSpecific.

-- If UserSpecific has a content model of #PCDATA, people can put whatever 
metadata they want in it.  The resulting file is valid, but forces the 
application to parse the PCDATA.

-- 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)





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS