[relax-ng] Comments on the compatibility spec

[MURATA Makoto <EB2M-MRT@asahi-net.or.jp>]

Major Technical

1. Normalization

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

Ideally, that normalization should be extended so that foreign
elements and attributes are moved to appropriate locations.  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.


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.

2.1 examples

Some ambiguous examples would help.  

1) default value ambiguity

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

and 

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

2) datatype ambiguity 

<element name="foo">
  <attribute name="bar">
    <data type="d:ID"/>
  </attribute>
</element>

and 

<element name="foo">
  <attribute name="bar">
    <data type="token"/>
  </attribute>
</element>

where "d" refers to the compatibility datatype library.

2.2 Reorganization

I would propose to move the fifth para ("In an XML 1.0 document"...)
and sixth para ("Some features"...) in the introduction to a new
section named "Ambiguity".  Then, the rest of the introduction will
become a lot easier to understand.

I would also propose to duplicate relevant conditions stated in
Sections 4 and 5 in the new section "Ambiguity".

	- the first child of this attribute element is a name element
	- the first child of the containing element element is a name element

Note: We also have to require that competing definitions specify 
identical info, if the next comment is declined.


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.


2.4 "it does not have a oneOrMore ancestor"

Do we really need this condition specified in Section 4?


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.


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.  But don't we have to extend
the Java interface for datatype libraries?


4. Minor

1)

The first para and the second para in the introduction should be 
swapped?

2) 

A below table in Section 3 would help.


        compatibility  soundness  infoset-modification

default      X            -              X

ID           X            X              X

doc          X            -              -



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

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.

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.

Cheers,

Makoto