Re: Various comments

[Jeni Tennison <mail@jenitennison.com>]

Hi James,

> Thanks for all your comments. I have replied to all except this one
> in separate messages.

And thanks for your replies :)

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

Fair enough. I can see it's a difficult area, and the current model
certain does add significantly to ID/IDREF.

So another question: given that it's the element or attribute that's
the key, rather than the value, is there any particular reason for
placing the key/keyRef attribute on the internal data element rather
than on the element or attribute element?

I ask because another (just) plausible situation might be where you
have enumerated values for a key.  For example, I might define a
document vocabulary in which I had an id attribute for each section,
which could take the fixed values 'abstract', 'introduction' or
'references', or a section number.

<element name="section">
   <attribute name="id">
      <choice>
         <value type="token">abstract</value>
         <value type="token">introduction</value>
         <value type="token">references</value>
         <data type="token">
            <param name="pattern">\d(.\d){0,}</param>
         </data>
      </choice>
   </attribute>
</element>

If I were allowing just a section number, I could turn this id
attribute into a key, using the key attribute on the data element.  As
it is, I can't, because I have a mix of value types for the attribute.

Putting the key attribute on the attribute/element element instead
would also save repetition if there were multiple data types allowed
for the attribute/element.

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/