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: Alternative approach for key/keyref


James,

I also think that a full-fledged solution to keys/keyRefs requires an
independent standard.  Descriptions of keys/keyRefs should be
separated from  grammars.

I agree that we need a simple extension of ID/IDREF in RELAX NG.
However, I dislike 7.4.  It is complicated, ad-hoc, and weak.
Moreover, application programmers have to find out how to locate keys.

The second para of 7.4 is:

    It must be possible to determine for any element or attribute whether
    it is a key or key reference and, if so, the symbol space of the key
    or key reference, by examining just the name of the element or
    attribute and the names of the ancestors of that element or
    attribute. ...

I would propose to replace "ancestors" with "parents", and to rewrite
this subsection accordingly.  Then, 7.4 will become a lot simpler and
we can still mimick ID/IDREF.

Here is my rewrite.

7.4 key and keyref

(The first para is the same as in the current draft.)

Two <element>s are said to overlap if some name matches both of their
nameclasses.  Likewise, two <attribute> elements are said to overlap
if some name matches both of their nameclasses.

The second child (i.e. pattern) of an <attribute> and that of an
ovelapping <attribute> shall be key-compatible, if these <attribute>s
occur in a single <element> or overlapping <element>s.

The second child of an <element> and that of an overlapping <element>
shall be key-compatible, if the <define>s containing these <element>s
are referenced from the same <element> or overlapping <elements>.

Two patterns are key-compatible if and only if

1) they are <key> elements of the same name and URI, 

2) they are <keyRef> elements of the same name and URI, or

3) neither of them contain <key> or <keyRef>.

>  Am I right in thinking there are other consistency issues apart 
> from datatypes?

For example?

> Section 7.4 looks long and complicated because it's spelling everything out 
> formally and rigourously with no hand-waving.  Even if we simplified it to 
> be closer to ID/IDREF (by for example not allowing keys to have separate 
> symbol spaces), 7.4 would not be much simpler.

I do not think that it is a good idea to stick to paths if you do 
not use path expressions.  As I have shown above, 7.4 becomes a lot 
simpler.

> 1. Adding a note explaining that our key/keyRef facility is intended as a 
> modest, very easy to use increment on ID/IDREF not as a comprehensive 
> solution for key/keyRefs and that more comprehensive solutions can be 
> layered on top of RELAX NG.

This is fine.

> 2. Possibly renaming key/keyRef to something else.  Leave the name 
> key/keyRef free for future, more comprehensive path-based approaches. 
> Perhaps use a term closer to ID/IDREF.  I think
> 
> <id>
>   <data type="token"/>
> </id>
> 
> is quite natural. Using "name" as the name of the attribute indicating the 
> ID symbol doesn't seem to fit very well with <id>, <idref>.  Maybe one 
> could use
> 
> <id class="...">...</id>
> 
> Such a "class" attribute should probably be optional.

This sounds fine to me.


Cheers,

Makoto


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC