[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: What is the advantage of RELAX in comparison to Schemas?
- From: Rick Jelliffe <firstname.lastname@example.org>
- To: email@example.com
- Date: Wed, 31 Jan 2001 03:18:58 +0800
From: David E. Cleary <firstname.lastname@example.org>
> From: ???
>> I'd like to think that the Schema WG might reconsider its decision to
>> omit context-aware constraints, though I'm aware that it's unlikely to
>> happen any time soon.
There are certain context-aware constraints possible: the provision of local
element definitions allows, in effect, the parent axis to be used (I think
only along paths all in the same namespace or none though.) And the
key/uniqueness mechanism uses a kind of XPath so quite a rich context can be
formed from it, as far as it goes.
> In the meantime, XML Schema has well defined extension mechanisms
> through either the appInfo element or the use of non-native attributes.
> These can be added directly to an XML Schema with affecting XML
> Schema validity. An application or second level validator can then use
> information to validate context-aware constraints. Instead of waiting for
> the XML Schema WG to create this functionality for a future version of
> XML Schema, create one yourself today so that the Schema WG can use
> it as input for the next version.
I think there are several things missing before the extensibility mechanisms
in XML Schemas are much practical use.
1) There needs to be widespread deployment of resolving code which handles
<include>,<import>,<redefine>, and the other forms of indirection. This is
either a transformation or some API which hides the details. I don't see
anything like this yet.
2) There needs to be support for the Post Schema Validation Infoset in the
major APIs: DOM and XPath. I don't see anything like this yet.
For example, if these are not available, you cannot really put any
constraints on abstract elements: you would have to define them separately
for each element that joins the substitution group and hope the separate
definitions keep in synch. (I am not talking about what vendors/programmres
who have access to the APIs can do; I am talking about the immediate
practicality of creating generic tools that work from the infoset of the
schema as exposed by today's standard APIs.)