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


Help: OASIS Mailing Lists Help | MarkMail Help

relax-ng message

[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