[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: Various comments
Thanks for all your comments. I have replied to all except this one in separate messages. key/keyRef doesn't aspire to be a general solution for enforcing all cross-reference constraints. Such a solution would require something like Schematron. Rather key/keyRef is just a modest cleanup/generalization of XML ID/IDREF, which we felt was the minimum that we had to support. It's a tough issue to decide where to draw the line for RELAX NG in terms of support for cross-reference constraints. At what point do you say, that's a job for Schematron or something similar? Not having any support at all is possible, but I think wouldn't be acceptable to users. I think users will require at least ID/IDREF. And if you are going to have ID/IDREF, you might as well clean it up and generalize it as we have done with key/keyRef. It adds little complexity over and above ID/IDREF, and maintains the clean separation between validation and datatyping. Should we extend key/keyRef? It is already quite hard to implement/specify: the extensions you suggest, whilst logically possible, would make it significantly harder, whilst still falling short of a fully general solution like Schematron. Jeni Tennison wrote: > Keys and KeyRefs: > > As you know, XML Schema has a number of built in data types, and you > can define more yourself. In a standalone schema (i.e. one that > doesn't import/include/redefine any others) then the type attribute on > a xs:attribute has to point to one of these types. > > The first thing here is that it's impossible to use key/keyRef in this > situation as RELAX NG currently stands because the type attribute > might point to a built-in type, one that isn't specified through a > simple type definition somewhere else in the schema. I can't do a > choice between a reference to a type and enumerated set of names > because of the restrictions on knowing whether an attribute is a > keyRef described at the bottom of Section 12. > > The second thing is that it would be useful to allow a particular > element/attribute to be a key in multiple symbol spaces. This comes > into play here because I want to make sure (a) that xs:simpleType and > xs:complexType names don't clash [i.e. have a 'types' symbol space] > and (b) that the type attribute of xs:attribute refers to *only* a > xs:simpleType [i.e. have a 'simpleTypes' symbol space]. So I'd like > to be able to do: > > <element name="simpleType"> > <attribute name="name"> > <!-- not current RELAX NG --> > <data type="NCName" key="types simpleTypes" /> > <!-- /not current RELAX NG --> > </attribute> > </element> > > <element name="element"> > <attribute name="type"> > <data type="NCName" keyRef="types" /> > </attribute> > </element> > > <element name="attribute"> > <attribute name="type"> > <data type="NCName" keyRef="simpleTypes" /> > </attribute> > </element> > > (In fact I can't use key/keyRef here at all, because of the multiple > documents and the fact that some complex namespace resolution goes on > because the type attributes in XML Schema are actually QNames and so > on, of course. I guess it's time to get Schematron out ;)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC