[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: extensibility in XSchema?

• From: "Simon St.Laurent" <SimonStL@c...>
• To: "Xml-Dev (E-mail)" <xml-dev@i...>
• Date: Mon, 29 Jun 98 13:06:18 UT

[It doesn't look like this made it to XML-Dev last night, so I'll try again.]

Where I'm going right now takes into account Friday's suggestions from Ron 
Bourret, John Cowan, and Paul Prescod.  Hopefully, the stew is a good one.  
Roughly,

XSchema processors are only responsible for handling information in the XSC 
namespace.  Extensible information is going to involve more than our basic 
framework provides.  XSchema will provide this information with a home, and 
make it available to applications, but this information will not be checked by 

XSchema itself.  Only the XSC namespace(i.e., core element/attribute) 
information will be managed by the XSchema processor.  This is sufficient for 
creating DTDs from XSchemas, while providing room for all the other 
information people need.  (This is my response to Paul's suggestion that 
XSchema processors only manage the XSC namespace.)

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.

Conformance is becoming more and more of an issue; sections 4.0 and 5.0 
(XSchema->DTD and XSchema processing) will need to address this head-on.  We 
can't make apps conform to portions of the standard which aren't specified, of 

course.

Versioning will be implemented through namespaces as well - I'll figure out 
the details on the src and ns URLs shortly.  I'm pondering PURL/versionNumber.

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.

The impact of these decisions on the XSchema DTD is at present fairly small.  
Unless I hear an uproar, many of the current empty elements will be moving to 
an attribute-based model in the next revisions of the attribute declaration 
and notation declarations.  There will also be an ANY content model (PCDATA 
seems too brutal) creeping into a space provided for non-XSC namespace 
extensions.  Namespaces do not appear to exempt elements from validation.  I 
would like XSchemas to be validatable if not governed by their validation.

John Cowan wrote:
>I think that both of these lose, and that UserSpecific is very ugly,
>et iterum censeo Carthago delenda est....

Carthago delenda est did come to an end with a peace treaty between the cities 

of Rome and Carthage in 1985.  Unfortunately, I don't see a much better 
solution at present.

Simon St.Laurent
Dynamic HTML: A Primer / XML: A Primer / Cookies


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

• Prev by Date: Passing #FIXED values through para. entity refrences
• Next by Date: XSchema Spec, Section 3, Draft 1 (Namespaces)
• Previous by thread: Re: extensibility in XSchema?
• Next by thread: Re: extensibility in XSchema?
• Index(es):
  • Date
  • Thread