Re: [relax-ng] Comments on the compatibility spec

[James Clark <jjc@jclark.com>]

> This spec depends on the normalization defined in the RELAX NG spec,
> but that normalization deletes a:defaultValue.

I agree this is a problem.

> Ideally, that normalization should be extended so that foreign
> elements and attributes are moved to appropriate locations.

I think that would be difficult in general.

> But I
> don't think that we can finish such a major change this month.
>
> As a tentative solution, I would propose to introduce another
> normalization in this specfication.  This normalization is identical
> to the normalization defined in the RELAX NG spec except that it does
> not remove a:defaultValue.  Introduction of this normalization is
> merely for convenience; we do not force implementations to have two
> normalizations.

This seems fine.  I think all we need to do is in Section 4 add a paragraph 
saying that the simplification used in this section does not remove 
a:defaultValue attributes occurring on <attribute> elements.

>
> 2. Ambiguity
>
> Most readers will find it difficult to understand the ambiguity
> problem.  Therefore, I would propose editorial changes as well as
> small technical changes.

I would rather not make substantial editorial changes at this very late 
stage.  Also I think your proposed changes would give a undue degree of 
prominence to the ambiguity issue.

> 2.3 Different competing declarations having the same default or ID-type
>
> Do we really have to allow coexistence of
>
> <element name="foo">
>   <optional><attribute name="bar" a:defaultValue="true"/></optional>
> </element>
>
> and
>
> <element name="foo">
>   <optional><attribute name="bar" a:defaultValue="true"/></optional>
> </element>
>
> ?
>
> The same question applies to ID, IDREF, and IDREFS.

The problem is that schema simplification does not preserve element 
identity.  What was one element in the original schema may end up as two 
elements after simplification.  A user will be surprised to get an error 
about multiple conflicting a:defaultValue attribute if their source schema 
contains only a single such attrinbute. Also implementations at the moment 
don't have to worry about element identity in the simplified schema so they 
can share structure. I suspect disallowing this would be tricky to 
implement.

Furthermore, implementations will typically want to normalize

  <choice>x x</choice>

into x.  (It's essential that derivative-based implementations do this.) 
If the compatibility spec required an error for

<choice>
  <element name="foo">
    <optional><attribute name="bar" a:defaultValue="true"/></optional>
  </element>
  <element name="foo">
    <optional><attribute name="bar" a:defaultValue="true"/></optional>
  </element>
</choice>

implementations that did such normalization of <choice> would have a major 
problem detecting this.

> 2.4 "it does not have a oneOrMore ancestor"
>
> Do we really need this condition specified in Section 4?

You're right: I don't think we do.  I've deleted it.

> 2.5 "context-dependent datatypes"
>
> If default values are only for compatibility with XML 1.0,
> we only have to consider those datatypes of XML Schema
> borrowed from XML 1.0.  Another simplification is to
> consider context-independent datatypes of XML Schema.

That would make the Compatibility spec dependent on XML Schema.  I don't 
think that's a good idea.

> 3. Other datatype libraries providing ID-types
>
> Do we really allow other datatype libraries to provide ID-types?  Such
> datatypes libraries are probably useful, especially when you create
> minor variations of XML Schema Part 2.

It is necessary if we want

(a) to avoid making the Compatibility spec dependent on XML Schema, and
(b) allow the XML Schema ID/IDREF types to get the treatment that the user 
expects

> But don't we have to extend
> the Java interface for datatype libraries?

We've done it already.

> 4. Minor
>
> 1)
>
> The first para and the second para in the introduction should be
> swapped?

The second para refers to "these extensibility mechanisms", which wouldn't 
make sense without the preceding bullet points.

> 2)
>
> A below table in Section 3 would help.
>
>
>         compatibility  soundness  infoset-modification
>
> default      X            -              X
>
> ID           X            X              X
>
> doc          X            -              -

If you want to mark it up, I'll put in in.

> 3)
>
> Section 4 introduces "a:defaultValue" without explaining what the
> prefix "a" refers to.  However, strictly speaking, Section 1 merely
> states that "EXAMPLES in this specification ..".

I think  we can just delete "Examples in" from that sentence in Section 1.

> 4)
>
> In the forth bullet in the itemized list in Section 5, we have "its
> parent attribute element".  James probably mentions another attribute
> element having the same ancestor element element.

I don't understand this comment.

> 5)
>
> Although the Guideline spec shows that "ID", "IDREF", and "IDREFS" of
> XML Schema also have ID-types, I would like to add a note about this.

OK.

I've put a new draft with the changes I mention above available at

http://www.thaiopensource.com/relaxng/compatibility.html

James