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


We are now at risk of disolving ourselves.  What are you willing to 
give up and what am I willing to give up?

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

You probably won't be suprised to hear I disagree 100%.  Some reasonable 
person (who is not a member of this TC) said to me that your position is 
inconsistent.

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

Because it is not consistent with DTDs and not consistent with 
recent reserach, which use path expressions.

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

I think this is your subjective claim.  I think that "the same as DTDs" is simple.

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

Disagree with the second sentence.  This is merely your subjective claim.

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

Disagree.

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

You are certainly the chair and you wrote the spec.  But which meeting report 
says that the TC has made such a decision?

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

I do not think "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".   Which meeting report say so?

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

As for this issue, I agree that this is a subjective issue.  But, as a general 
principle, I am  hesitant to go beyond DTDs.

>> 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 agree on this wording. 

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

I find this proposal interesting.  The only difference between my proposal 
and this proposal is that element cannot be used as keys and that keys are not 
typed.  Apparently, this approach helps when db people start to criticize the current 
mechanism.

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

I agree that "I don't think positions in between make a whole lot of sense."  
But I think that one position is the same as ID/IDREF/IDREFS and the other is 
path-expressions-based rather than the current spec.  I think the current 
spec is in between.

Cheers,

Makoto


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


Powered by eList eXpress LLC