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: [relax-ng] Comments on the compatibility spec

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

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 name="foo">
  <optional><attribute name="bar" a:defaultValue="true"/></optional>

2) datatype ambiguity 

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


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

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 name="foo">
  <optional><attribute name="bar" a:defaultValue="true"/></optional>


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


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


A below table in Section 3 would help.

        compatibility  soundness  infoset-modification

default      X            -              X

ID           X            X              X

doc          X            -              -


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


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.


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.



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

Powered by eList eXpress LLC