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: RELAX NG telcon 12 June 2001




--On 12 July 2001 09:41 +0900 Murata Makoto <mura034@attglobal.net> wrote:

> James Clark wrote:
>
>> Note that the ambiguity criteria for key/keyRef is NOT currently an open
>> issue. Issue 43 is only about changing from an attribute syntax to an
>> element syntax for key/keyRef.
>
> What is "keyAtts"?

You are referring to the restricted grammar.  It's a bug. The references to 
keyAtts should be deleted.

> Our Minutes 2001-05-03 says:
>
>> 3. IDREFS support? IDREFS in XML 1.0 are a white-space separated list of
>> IDs in attribute values only. Agreed that there was not a great need for
>> this in 1.0.

We agreed this wasn't an absolute requirement. As I rememeber it, it fell 
into the "nice if we could get it without too much trouble" category.  We 
added <list> after we added key/keyRef.  I don't remember whether we 
discussed the issue of whether key/keyRef should be allowed inside <list>. 
I am happy to consider this as being an open issue.

> But <list><key ...>...</key></list> is allowed by 7.1 and 7.4.

So you don't want to allow <key> and <keyRef> inside <list>?  I've 
implemented this and I can report that it is indeed a bit tricky to 
implement. It also adds a bit of complexity to the spec.  On the other hand 
IDREFs are an XML 1.0 DTD feature that is purely to do with validation. At 
the moment, are there any things in XML 1.0 we can't handle other than 
those that change the infoset?

Note that the spec doesn't allowed <list> inside <key>/<keyRef> (because it 
adds complexity for comparing thigns for equality).

James






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


Powered by eList eXpress LLC