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: key/keyRef: generalization, ad-hocness,and generalization of ad-hocness



> James and I agree that a truly generalized solution for identity
> constraints is based on path expressions.  Such a solution would cover
> multi-part keys, scoped keys, and composite-element keys (e.g.,
> <name>Murata<ruby>murata</ruby></name)).  Furthermore, indenty
> constraints are likely to be separated from grammars.

I also think such a mechanism would be significantly harder to to use than 
our current mechanism.  Thus, I think our current mechanism would have 
value even if we had such a fully generalized mechanism.

>   (1) paths of arbitrary lengths (e.g., paragarphs in
>     chapters/sections/subsections are identified by numbers,
>     but paragaraphs in column articles are not).

Since RELAX NG allows the content model of an element to depend on the 
context, it seems bizarre not to allow the key/keyRef-ness of a content 
model to depend on its context.  If I can say that a paragraph in a 
chapter/section/subsection has a different content model from a paragraph 
in an article, why cannot I say that it has a different key/keyRef?

>   (2) key/keyRef declarations can be combined with <choice> (see the
>      production rule for the non-terminal "value")

I think this is a simplification not a complication.

>   (3) key/keyRef declarations can be combined with <list> (again, see the
>      production rule for the non-terminal "value")

We need keyRef in list for IDREF.  Allowing free combination is simpler 
than placing restrictions.

>   (4) key/keyRef declarations within <list> can be freely combined
>      with <oneOrMore>, <interleave>, <group>, and <choice> (see the
>      production rule for the non-terminal "tokens")

I think this is a simplification not a complication.

> I think that (1) is a back-handed mechanism for path expressions.  A
> truly generalized approach is sketched by [1] and is presented in my
> PDOS 2001 paper.  I think that it is very ad-hoc to mimick path
> expressions by tree grammars.  I propose to have an issue in our issue
> list.  I am not sure if the TC has officially made any decision about
> this.

Sorry, we DID make a decision on this.  We explicitly decided to adopt the 
key-ambiguity algorithm based on the ancestry of an element.

> [1] http://lists.oasis-open.org/archives/relax-ng/200107/msg00089.html
>
> I also think that (2) is a doubtful generalization.  I believe that
> the TC has never discussed about this and this part of the current
> spec is not status quo.  I think that this should automatically become
> an issue since no consensus has ever existed.

I disagree.  We decided this when we agreed to adopt the key and keyRef 
attributes on data.  We adopted the key and keyRef attributes on data 
without imposing any restrictions with respect to choice other than those 
of the key-ambiguity algorithm.  If you want a new issue, you must follow 
our process and get 2 other people.

In my view it makes absolutely no sense to disallow

<element name="foo">
 <choice>
   <key>...</key>
   <key>...</key>
 </choice>
</element>

when you can have

<choice>
  <element name="foo">
    <key>...</key>
  </element>
  <element name="foo">
    <key>...</key>
  </element>
</choice>


> In my understanding, the semantic rule (keyAmbig) disallows almost all
> <choice> elements containing <key> or <keyRef>.  It allows <choice>p1
> p2</choice>, only if p1 and p2 have exactly the same key-types.  Do
> people see any values in allowing
>
> <choice>
>   <key name="foo">
>     <data type="short"><param  name="minInclusive">100</param></data>
>   </key>
>   <key name="foo">
>     <value type="short">-1</value>
>   </key>
> </choice>
>
> ?  I do not think that this feature deserves the complexity of the
> spec.

I don't believe this feature does complicates the spec.

> Issue 56 includes (3).  I think that (3) is reasonable for <keyRef>
> but unreasonable for <key>.  Don't be deceived by superfitial
> symmetricity.  If an element or attribute contains a list of keyRefs
> (i.e., IDREFS), we conceptually have multiple reference objects.  The
> rest of the story is simple.  However, if an element or attribute
> contains a list of key, we destroy one-to-one correspondences between
> identifiers and elements/attributes and go far beyond ID/IDREF or
> identity constraints studied in the database community.
>
> I think that (4) is really bad.  I believe that the TC has never
> discussed about this and that this part of the spec is not status quo.
> I think that this should automatically become an issue since no
> consensus has ever existed.

I think this is appropriately covered by the key/keyRef in list issue. We 
can make this issue be: what to do about key/keyRef in list?  Disallow it 
altogether, or allow with restrictions?

I think the reasonable alternative to our current design is something 
stricly limited to XML 1.0 features, ie you have empty <ID>, <IDREF> and 
<IDREFS> elements and allow them only as a child of <attribute> (in the 
normalized form).  I would support adding this as an issue. However, if we 
are doing this, I think it would be probably better to do it as a common 
annotation on <attribute>.  That would certainly simplify the spec. In this 
case, I think we really do have to have a common annotations spec.

The basic ID/IDREF approach is that the schema labels the things that are 
ID/IDREFs.  Our key/keyRef approach is to generalize this basic approach as 
much as possible, whilst still sticking to the idea that the schema labels 
things that serve as key/keyRefs.  An alternative reasonable approach is 
not to generalize at all.  I don't think positions in between make a whole 
lot of sense.

James





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


Powered by eList eXpress LLC