--------------------------------------------------------------------------
                                                 Date:        Document:
                                                 2001-08-09   **ISO/**
                                                              **22250-1**
  ---------------------------------------------- ------------ --------------
                                                              

  --------------------------------------------------------------------------

+---+------+------+------+--------------------+----------------------+
| * | **   | *    | **   | **Comment**        | **Disposition agreed |
| * | Clau | *Par | Type |                    | in Ballot Resolution |
| M | se/\ | agra | of   |                    | Meeting**            |
| e | sub  | ph/\ | c    |                    |                      |
| m | clau | Fi   | omme |                    |                      |
| b | se** | gure | nt** |                    |                      |
| e |      | /Tab | (g   |                    |                      |
| r |      | le** | ener |                    |                      |
| \ |      |      | al/\ |                    |                      |
| b |      |      | tech |                    |                      |
| o |      |      | nica |                    |                      |
| d |      |      | l/ed |                    |                      |
| y |      |      | itor |                    |                      |
| * |      |      | ial) |                    |                      |
| * |      |      |      |                    |                      |
+===+======+======+======+====================+======================+
| F |      |      | Gen  | Disapproval,       | Accept. This         |
| R |      |      | eral | because            | specification is not |
| A |      |      |      | specifications to  | an IS bur rather a   |
| N |      |      |      | describe markup    | TR. The coversheet   |
| C |      |      |      | languages          | of the DTR is        |
| E |      |      |      | containing a XML   | incorrect.           |
|   |      |      |      | scheme should not  |                      |
|   |      |      |      | be given in a      |                      |
|   |      |      |      | standard.          |                      |
|   |      |      |      |                    |                      |
|   |      |      |      | We would change    |                      |
|   |      |      |      | our negative vote  |                      |
|   |      |      |      | in a positive one  |                      |
|   |      |      |      | if this document   |                      |
|   |      |      |      | was published as a |                      |
|   |      |      |      | technical report.  |                      |
+---+------+------+------+--------------------+----------------------+

<table>
<colgroup>
<col style="width: 6%" />
<col style="width: 0%" />
<col style="width: 9%" />
<col style="width: 0%" />
<col style="width: 9%" />
<col style="width: 10%" />
<col style="width: 0%" />
<col style="width: 30%" />
<col style="width: 32%" />
<col style="width: 0%" />
</colgroup>
<thead>
<tr class="header">
<th colspan="2"><strong>Member<br />
body</strong></th>
<th colspan="2"><strong>Clause/<br />
subclause</strong></th>
<th><strong>Paragraph/<br />
Figure/Table</strong></th>
<th colspan="2"><strong>Type of comment</strong> (general/<br />
technical/editorial)</th>
<th><strong>Comment</strong></th>
<th colspan="2"><strong>Disposition agreed in Ballot Resolution
Meeting</strong></th>
</tr>
</thead>
<tbody>
<tr class="odd">
<td colspan="2">NL</td>
<td colspan="2"></td>
<td></td>
<td colspan="2">General</td>
<td><p>The Dutch national body is pleased by the Japanese proposal for
the RELAX standard, and regrets that it has not been able to take proper
time to give the proposal the careful attendanc it deserves. It
apologises for making remarks at a moment wehere there is little or no
time to discuss them. Most remarks are editorial, some however are
fundamental, especially where this</p>
<p>proposed International Standard refers to and relies on a Working
Draft Recommendation of the W3C.</p>
<p>For the datatypes, RELAX relies on the Working Draft of XML Schema
Part 2.W3C Working Drafts are not stable and should not be the
fundaments of an IS. We can support this standard only if</p>
<p>a. all references to XML Schema are changed to informative, and RELAX
specifies its own datatypes, or</p>
<p>b. when XML Schema 2 is a finished recommendation, in which case
RELAX should refer explicitly to that finished recommendation and should
not mention any datatypes itself, nor in clause 7.2 or in Annex
B2.</p></td>
<td colspan="2">Accept. Since XML Schema Part 2 is now a W3C
recommendation, we choose option b). Delete subsections of 7.2 and 7.4,
but retain descriptions specific to RELAX Core.</td>
</tr>
<tr class="even">
<td colspan="2">NL</td>
<td colspan="2"></td>
<td>Annex A</td>
<td colspan="2"></td>
<td>Remarks 7d and 7e identify errors in Annex A that should be
resolved.</td>
<td colspan="2">Accept. See 7d and 7e.</td>
</tr>
<tr class="odd">
<td colspan="2">NL</td>
<td colspan="2">Clause 2,</td>
<td></td>
<td colspan="2"></td>
<td><p>References. A direct reference to ISO 8879, SGML, should be
added, since clause 3.5.1 refers to that IS [see remark 3]. The
indirect</p>
<p>reference through the reference of XML 1.0 is not sufficient to
resolve clause 3.5.1 easily.</p></td>
<td colspan="2">Accept. Add a reference to ISO 8879 in Section 2.</td>
</tr>
<tr class="even">
<td colspan="2">NL</td>
<td colspan="2">Clause 2</td>
<td></td>
<td colspan="2"></td>
<td><p>References. XML Information Set and XML Schema Part 2 are refered
to as Working Drafts. These should and can not be the base of an
International Standard; W3C explicitly warns against any actual usage of
Working Drafts. The link to Schema Part 2 however does not point to a
Working Draft or any specific version, but to the Current Version,
whatever that may be (on May 1st 2001 it happens to be a Proposed
Recommendation). To what does DTR 22250-1 refer? To the Working Draft
(as said explicitly, but not to what version of that Draft) or to the
current version of the recommendation (where the link leads to)? Should
an International Standard refer to an unspecified version of something?
Should an International tandard refer to an unfinished Working Draft
that forbids to be refered to?</p>
<p>No. We propose therefore that these references should be made
either</p>
<p>A. a. informative and b. explicitly to the version of the Working
Draft as it was on the time the IS was proposed; or</p>
<p>B. to "the most recent version of the Recommendation", in which case
we would rely on the W3C's willingness to provide backwards
compatibility, and</p>
<p>in which case all normative references to datatype in RELAX should be
removed, to avoid ambiguity.</p>
<p>Since we rather don't want to standardize anything that we don't
know, we would rather refer to an unambiguously specified version that
was known to the voters at the time of voting, so we propose to refer to
the Working Draft as it was on 2000-09-22, since that was the version
that was known at</p>
<p>the time this IS was written.</p>
<p>The fact that all datatypes used in RELAX are mentioned explicitly in
clause 7 makes it easier to make the reference to XML Schema Part 2 only
informative [see remark 6].</p></td>
<td colspan="2"><p>Since this technical report is a type 3 technical
report (experimental) of ISO, we can reference to candidate
recommendations of W3C.</p>
<p>Accept B). We normatively reference to XML Schema Part 2 and rely on
the W3C’s willingness to provide backwards compatibility.</p></td>
</tr>
<tr class="odd">
<td colspan="2">NL</td>
<td colspan="2">Clause 3.5.1</td>
<td></td>
<td colspan="2"></td>
<td>tag name. Refers to ISO 8879 which is not in the list of
references.</td>
<td colspan="2">Accept. Reference to ISO 8879 in Section 2.</td>
</tr>
<tr class="even">
<td colspan="2">NL</td>
<td colspan="2">Clause 4</td>
<td></td>
<td colspan="2"></td>
<td>Notations. Example 1 describes a content model with "finally an
optional backmatter", so in the content model fragment "backmatter*"
should be changed to "backmatter?", otherwise the backmatter is also
repeatable, which is only common for cats with nine tails</td>
<td colspan="2">Accept. Replace “*” with “?”</td>
</tr>
<tr class="odd">
<td colspan="2">NL</td>
<td colspan="2">Clause 5.2</td>
<td></td>
<td colspan="2"></td>
<td>Shouldn't the definitions in clause 5.2 and further be placed in
clause 3, Terms and definitions?</td>
<td colspan="2">Since this document is a type 3 technical report, we do
not have to strictly follow the editing guideline. For readability
reasons, we would like to have definitions in appropriate places in this
document.</td>
</tr>
<tr class="even">
<td colspan="2">NL</td>
<td colspan="2">Clause 7</td>
<td></td>
<td colspan="2"></td>
<td>If XML Schema Part 2 stays a normative reference, clause 7.2 is
redundant, with all maintanance risks. If Clause 7 stays normative,
there is a possible conflict with XML Schema Part 2 (f.i., in the
previous working draft (March 16) the "decimal" type was accidentally
renamed in "number", so which datatype applied to RELAX on March 17
2001?). Either the reference to XML Schema or clause 7.2 should
therefore be changed from normative to informative. Our preference is to
make the reference to XML Schema informative [see remark 2], so that
RELAX can define itself completely.</td>
<td colspan="2">Accept. Remove subsections of 7.2 but retain text
specific to RELAX Core.</td>
</tr>
<tr class="odd">
<td colspan="2">NL</td>
<td colspan="2">Annex A</td>
<td></td>
<td colspan="2"></td>
<td><p>Annex A: DTD for RELAX Core</p>
<p>a. is this Annex Normative or Informative?</p></td>
<td colspan="2"><ol type="a">
<li><p>This document is entirely informative. Thus, this annex is also
informative.</p></li>
</ol></td>
</tr>
<tr class="even">
<td colspan="2">NL</td>
<td colspan="2">Annex A</td>
<td></td>
<td colspan="2"></td>
<td>b. The DTD refers to "datatypes.dtd", which is a local file with
unknown content. That should be a URI to the appropriate version of that
DTD.</td>
<td colspan="2"><ol start="2" type="a">
<li><p>Accept. Add a URI for the datatype.dtd of W3C. The URL is
http://www.w3.org/2001/datatypes.dtd.</p></li>
</ol></td>
</tr>
<tr class="odd">
<td colspan="2">NL</td>
<td colspan="2">Annex A</td>
<td></td>
<td colspan="2"></td>
<td><p>c. The DTD is unparseable, since it refers to the parameter
entity "%annotation;" which is not defined in this DTD. The dataypes.dtd
from XML</p>
<p>Schema Type 2 (as it was on 2001-05-01) doesn't define it either, but
uses it as well. This is not strange, since this DTD is not intented for
the usage as made in RELAX (although it is intended for a similar
usage).</p>
<p>datatype.dtd explicitly states:</p>
<p>This DTD cannot be used on its own, it is intended only for
incorporation in XMLSchema.dtd, q.v.</p>
<p>A parameter entity declaration for %annotation; should therefore be
added to the RELAX.DTD.</p></td>
<td colspan="2"><ol start="3" type="a">
<li><p>Accept. Fix the DTD by adding definitions of annotation,
etc.</p></li>
</ol></td>
</tr>
<tr class="even">
<td colspan="2">NL</td>
<td colspan="2">Annex A</td>
<td></td>
<td colspan="2"></td>
<td><p>d. The elements annotation and documentation (as used in the
RELAX module</p>
<p>for RELAX core) should be defined in the Relax DTD, as they are in
the XML</p>
<p>Schema DTD [see also remark 8b]</p></td>
<td colspan="2"><ol start="4" type="a">
<li><p>Accept. Add “annotation”, “documentation”, and
“appinfo”.</p></li>
</ol></td>
</tr>
<tr class="odd">
<td colspan="2">NL</td>
<td colspan="2">Annex A</td>
<td></td>
<td colspan="2"></td>
<td><p>e. The DTD would be simpler in terms of unnecessary nesting
groups if the</p>
<p>brackets in the definition of the parameter entities %clause,
%rule,</p>
<p>%particle and %clauseBody were removed</p></td>
<td colspan="2"><ol start="5" type="a">
<li><p>Accept. Remove brackets.</p></li>
</ol></td>
</tr>
<tr class="even">
<td colspan="2">NL</td>
<td colspan="2">Annex A</td>
<td></td>
<td colspan="2"></td>
<td><p>f. The way the parameter entity %repeatable is referred to,
suggests that the leading and ending white space, inlcuding the record
delimiters, in the</p>
<p>replacement text is not necessary. Readability would be improved by
removing</p>
<p>the leading and ending white space in the parameter literal in the
declaration of %repeatable</p></td>
<td colspan="2"><ol start="6" type="a">
<li><p>Accept. Remove unnecessary whitespace.</p></li>
</ol></td>
</tr>
<tr class="odd">
<td>NL</td>
<td colspan="2">Annex B</td>
<td colspan="2"></td>
<td></td>
<td colspan="2"><p>Annex B.</p>
<p>a. is this Annex Normative or Informative?</p>
<p>b. The module is not valid XML, since it uses instances of element
types annotation and documentation that are not declared in the RELAX
core DTD.</p>
<p>c. Annex B2 defines Datatypes, that are also defined in XML Schema
Part 2. Which takes precedence, if there is a conflict?</p></td>
<td><ol type="a">
<li><p>Everything in this Technical Report is informative.</p></li>
<li><p>Accept. Fix the DTD.</p></li>
<li><p>Accept. Clearly state that XML Schema Part 2 is authoritative and
this annex is informational.</p></li>
</ol></td>
<td></td>
</tr>
</tbody>
</table>

<table style="width:100%;">
<colgroup>
<col style="width: 6%" />
<col style="width: 0%" />
<col style="width: 9%" />
<col style="width: 0%" />
<col style="width: 9%" />
<col style="width: 0%" />
<col style="width: 10%" />
<col style="width: 0%" />
<col style="width: 30%" />
<col style="width: 0%" />
<col style="width: 32%" />
</colgroup>
<tbody>
<tr class="odd">
<td colspan="2"><strong>Member<br />
body</strong></td>
<td colspan="2"><strong>Clause/<br />
subclause</strong></td>
<td colspan="2"><strong>Paragraph/<br />
Figure/Table</strong></td>
<td colspan="2"><strong>Type of comment</strong> (general/<br />
technical/editorial)</td>
<td colspan="2"><strong>Comment</strong></td>
<td><strong>Disposition agreed in Ballot Resolution
Meeting</strong></td>
</tr>
<tr class="even">
<td>BSI</td>
<td colspan="2">General</td>
<td colspan="2"></td>
<td colspan="2">General</td>
<td colspan="2"><p>In general the text is too sparse and provides no
informative examples that help readers to grasp the context in which
actions are taking place. Without these examples much of the text is
meaningless. ISO technical reports are meant to be informative in
nature. While sparse text is sometimes acceptable for standards for
which explanatory matter is provided in associated technical reports it
is generally the case that sparse standards are not used as they are too
difficult for users to understand.</p>
<p>(This report could not be published as a W3C report as it fails to
follow the rules of comprehensibility laid down by W3C. I would expect
it to fail at ISO for the same reasons.)</p>
<p>In general RELAX is a subset of XML Schemas, and relies heavily on
users having a detailed knowledge of this specification (particularly
Part 2) and related standards such as the Document Object Model and the
XML Infoset (though it fails to adopt the terminology of the latter,
though it is the official terminology of XML).</p></td>
<td colspan="2"><p>Accept. Add a note which references to ” HOW TO
RELAX” in “Basic Concepts” (in 5.1)</p>
<p>An ISO technical report provides information about mechanisms in the
scope of the TR. It does not have to provide information about
mechanisms outside the scope.</p></td>
</tr>
<tr class="odd">
<td>BSI</td>
<td colspan="2"><strong>2</strong></td>
<td colspan="2"></td>
<td colspan="2">technical</td>
<td colspan="2"><p>Those terms in XML that are inherited from ISO 8879
should be acknowledged by reference to their originating source.</p>
<p>The specification does not conform to the XML Information Set
definitions of terms, which W3C are now applying to all XML-related
standards.</p></td>
<td colspan="2"><p>Accept. Add a reference to ISO 8879.</p>
<p>Accept. Wherever possible, we borrow terms in the XML Information Set
specification.</p></td>
</tr>
<tr class="even">
<td>BSI</td>
<td colspan="2"><h5 id="section"> <strong>5.6</strong></h5></td>
<td colspan="2"></td>
<td colspan="2">technical</td>
<td colspan="2">RELAX only uses the pre-defined “built-in” XML
datatypes, which fail to meet a large part of user needs. XML Schemas
correctly recognize the need for users to be able to further constrain
the built-in datatypes, using patterns, etc, and to build datatypes that
are extensions to built-in datatypes.</td>
<td colspan="2">Accept in principle. Addition of such user-defined
datatypes should be considered later (probably as part of RELAX
Namespace).</td>
</tr>
<tr class="odd">
<td>BSI</td>
<td colspan="2"><strong>5.7</strong></td>
<td colspan="2"></td>
<td colspan="2">technical</td>
<td colspan="2"><p>The term “tag” as defined here conflicts with that in
8879, where it is defined as “descriptive markup”, which is the sense it
which it is used throughout the XML specification (and is the sense used
in definitions of phrases containing the word tag in the Definitions
clause).</p>
<p>The second paragraph of this section is not readily comprehensible.
(The word “condition” has no previously defined meaning.)</p></td>
<td colspan="2"><p>Accept. This Technical Report borrows “tag name” from
the terminology of DOM. Add a note about this term.</p>
<p>Accept. It should read “specifies a permissible tag name”.</p></td>
</tr>
<tr class="even">
<td>BSI</td>
<td colspan="2"><strong>5.8.1</strong></td>
<td colspan="2"></td>
<td colspan="2">technical</td>
<td colspan="2"><p>The restriction that elementRules and hedgeRules may
not share a label suggests they are being unnecessarily being
constrained to form a single namespace.</p>
<p>Constraining elementRules sharing labels to a single built-in
datatype will restrict their application.</p></td>
<td colspan="2">The restriction makes it easier to generate Java
programs from RELAX modules. If we provide more than one symbol spacezv
users will find the language more difficult to understand.</td>
</tr>
<tr class="odd">
<td>BSI</td>
<td colspan="2"><strong>6.1</strong></td>
<td colspan="2"></td>
<td colspan="2">editorial</td>
<td colspan="2">The last two URLs in this section are incorrect.</td>
<td colspan="2">Accept. Use the correct URL:
http://www.xml.gr.jp/xmlns/relaxCore</td>
</tr>
<tr class="even">
<td>BSI</td>
<td colspan="2"><strong>6.4</strong></td>
<td colspan="2"></td>
<td colspan="2">technical</td>
<td colspan="2">See comment ref 5.7 on inappropriate application of the
term tag. A better name would be “conditions”</td>
<td colspan="2">See the disposition of 5.7.</td>
</tr>
<tr class="odd">
<td>BSI</td>
<td colspan="2"><strong>6.8</strong></td>
<td colspan="2"></td>
<td colspan="2">technical</td>
<td colspan="2">ElementRules cannot contain “bags” whereby all element
must occur but the sequence is undefined (viz &amp; in SGML or
&lt;all&gt; in XML schemas)</td>
<td colspan="2">Since bags complicates validation, RELAX Core does not
provide it.</td>
</tr>
<tr class="even">
<td>BSI</td>
<td colspan="2"><strong>6.10 etc</strong></td>
<td colspan="2"></td>
<td colspan="2">technical</td>
<td colspan="2"><h5 id="section-1"></h5>
<p>It should be made clear that “” is the default value for occurs. The
meaning of the permitted symbols needs to be defined as these
definitions are not referenced in 2, and are currently not defined until
6.13.</p></td>
<td colspan="2">Accept. Add “When the occurs attribute is not
specified”.</td>
</tr>
<tr class="odd">
<td>BSI</td>
<td colspan="2"><strong>6.12</strong></td>
<td colspan="2"></td>
<td colspan="2">technical</td>
<td colspan="2"><p>Heading is incorrect</p>
<p>Why in last label in sequence I<sub>1n1</sub> instead of
I<sub>1n</sub>? (Same applies for subsequent lists.)</p></td>
<td colspan="2"><p>Accept. The header should be sequence rather than
squence.</p>
<p>I<sub>1n1</sub> is intended to be a suffix of a suffix. Use
I<sub>1i</sub> , instead.</p></td>
</tr>
<tr class="even">
<td>BSI</td>
<td colspan="2"><strong>7.2.10</strong></td>
<td colspan="2"></td>
<td colspan="2">technical</td>
<td colspan="2"><h5 id="section-2"></h5>
<p>There should be some mechanism for using ID attributes as
labels.</p></td>
<td colspan="2">In fact, values of ID attributes can be used to
reference to elements.</td>
</tr>
<tr class="odd">
<td>BSI</td>
<td colspan="2"><strong>7.2.13</strong></td>
<td colspan="2"></td>
<td colspan="2">technical</td>
<td colspan="2">As RELAX provides no mechanism for defining notations
the last paragraph is nonsense. (Or are we to presume that RELAX only
works when a DTD has already been defined for the relevant data
instance? If so this must be very clearly and unambiguously stated at
the start of the document.)</td>
<td colspan="2"><p>Accept. Add a paragraph (see below) in the scope.</p>
<blockquote>
<p>The RELAX specification may be used in conjunction with DTDs. In
particular, notations and entities declared by DTDs can be constrained
by RELAX.</p>
</blockquote></td>
</tr>
<tr class="even">
<td>BSI</td>
<td colspan="2"><strong>7.4</strong></td>
<td colspan="2"></td>
<td colspan="2">technical</td>
<td colspan="2"><p>Why are Patterns not also inherited from XML Schema
Part 2?</p>
<p>Without any examples of the use of facets any where in the technical
report the statements in this section are generally
meaningless.</p></td>
<td colspan="2"><p>Actually, it is inherited.</p>
<p>Examples are shown in other introductory documents such as “HOW TO
RELAX”.</p></td>
</tr>
</tbody>
</table>

  ---------------------------------------------------------------------------------------------------------------
  **Member\   **Clause/\    **Paragraph/\    **Type of comment**    **Comment**           **Disposition agreed in
  body**      subclause**   Figure/Table**   (general/\                                   Ballot Resolution
                                             technical/editorial)                         Meeting**
  ----------- ------------- ---------------- ---------------------- --------------------- -----------------------
  USA         Part 1: RELAX                  General                1\. RELAX in its      Accept. A note shall be
              Core                                                  current form is       added to describe this
                                                                    purely for XML and    relationship. XML is a
                                                                    logically belongs in  subset of WebSGML,
                                                                    the W3C, not the ISO. which is a part of the
                                                                    Text should be added  SGML standard. In this
                                                                    to show its           sense, RELAX Core is
                                                                    applicability to ISO  applicable to SGML.
                                                                    8879 (e.g., as an     
                                                                    alternative notation  
                                                                    for document type     
                                                                    definitions), if      
                                                                    indeed it has such    
                                                                    applicability. (Item  
                                                                    2 below would also    
                                                                    help in this regard.) 

  USA         Part 1: RELAX                  General                2\. Also, there is no Accept in principle. It
              Core                                                  provision for         certainly makes sense
                                                                    round-trip lossless   to create such a
                                                                    conversion between    specification in the
                                                                    RELAX schema          future, and the RELAX
                                                                    definitions and DTDs  Core TR can be used
                                                                    with respect to       together with such a
                                                                    datatypes. The RELAX  specification.
                                                                    TR should include an  
                                                                    equivalent DTD        
                                                                    representation of     
                                                                    datatypes that is     
                                                                    capable of being      
                                                                    verified with         
                                                                    existing SAX and DOM  
                                                                    implementations.      

  USA         Part 1: RELAX                  General                3\. Because this TR   Accept.
              Core                                                  is coming from an     
                                                                    outside source where  
                                                                    it is freely          
                                                                    available on the WWW, 
                                                                    it should continue to 
                                                                    be available after    
                                                                    adoption.             
  ---------------------------------------------------------------------------------------------------------------

+---+------+------+------+---------------------+----------------------+
| * | **   | *    | **   | **Comment**         | **Disposition agreed |
| * | Clau | *Par | Type |                     | in Ballot Resolution |
| M | se/\ | agra | of   |                     | Meeting**            |
| e | sub  | ph/\ | c    |                     |                      |
| m | clau | Fi   | omme |                     |                      |
| b | se** | gure | nt** |                     |                      |
| e |      | /Tab | (g   |                     |                      |
| r |      | le** | ener |                     |                      |
| \ |      |      | al/\ |                     |                      |
| b |      |      | tech |                     |                      |
| o |      |      | nica |                     |                      |
| d |      |      | l/ed |                     |                      |
| y |      |      | itor |                     |                      |
| * |      |      | ial) |                     |                      |
| * |      |      |      |                     |                      |
+===+======+======+======+=====================+======================+
| J | Gen  |      | Gen  | 1\. Changes for     | Accept in principle. |
| P | eral |      | eral | harmonizing with    | Actual harmonization |
| N |      |      |      | RELAX Namespace     | should be done by    |
|   |      |      |      |                     | the upcoming RELAX   |
|   |      |      |      | Add the attribute   | Namespace            |
|   |      |      |      | \"namespace\" to    | specification rather |
|   |      |      |      | ref/hedgeRef.       | than in this TR.     |
+---+------+------+------+---------------------+----------------------+
| J | 6    |      | T    | Introduce           | Accept in principle. |
| P |      |      | echn | \<hedgeExport\> as  | Actual harmonization |
| N |      |      | ical | a subordinate of    | should be done by    |
|   |      |      |      | \<interface\>. The  | the upcoming RELAX   |
|   |      |      |      | only permissible    | Namespace            |
|   |      |      |      | attribute is        | specification rather |
|   |      |      |      | \"label\".          | than in this TR.     |
+---+------+------+------+---------------------+----------------------+
| J | 6    |      |      | Add the attibute    | Accept in principle. |
| P |      |      |      | \"role\" to         | Actual harmonization |
| N |      |      |      | \<export\>. An      | should be done by    |
|   |      |      |      | \<export\> element  | the upcoming RELAX   |
|   |      |      |      | may specify either  | Namespace            |
|   |      |      |      | this attribute or   | specification rather |
|   |      |      |      | the attribute       | than in this TR.     |
|   |      |      |      | \"label\".          |                      |
+---+------+------+------+---------------------+----------------------+
| J | 6    |      |      | Allow wildcards for | Accept in principle. |
| P |      |      |      | elements/attributes | This should be done  |
| N |      |      |      | for foreign         | by the upcoming      |
|   |      |      |      | namespaces.         | RELAX Namespace      |
|   |      |      |      |                     | specification rather |
|   |      |      |      |                     | than in this TR.     |
+---+------+------+------+---------------------+----------------------+
| J | Gen  |      |      | 2\. Changes for     | Accept. Delete       |
| P | eral |      |      | harmonizing with    | subsections of 7.2   |
| N |      |      |      | the 2nd Proposed    | and 7.4, but retain  |
|   |      |      |      | Recommendation, XML | descriptions         |
|   |      |      |      | Schema Part 2       | specific to RELAX    |
|   |      |      |      |                     | Core.                |
|   |      |      |      | Revise permissible  |                      |
|   |      |      |      | datatypes and       |                      |
|   |      |      |      | facets accordingly. |                      |
+---+------+------+------+---------------------+----------------------+
| J | 6    |      |      | Introduce           | Accept in principle. |
| P |      |      |      | user-defined        | This should be done  |
| N |      |      |      | datatypes based on  | by the upcoming      |
|   |      |      |      | XML Schema Part 2.  | RELAX Namespace      |
|   |      |      |      |                     | specification rather |
|   |      |      |      |                     | than in this TR.     |
+---+------+------+------+---------------------+----------------------+
| J | 7    |      |      | Allow URI           | This is already      |
| P |      |      |      | references          | allowed by XML       |
| N |      |      |      | containing          | Schema Part 2, and   |
|   |      |      |      | non-ascii           | is thus allowed by   |
|   |      |      |      | characters.         | RELAX Core.          |
+---+------+------+------+---------------------+----------------------+

  ---------------------------------------------------------------------------------------------------------------
  **Member\   **Clause/\    **Paragraph/\    **Type of comment**    **Comment**           **Disposition agreed in
  body**      subclause**   Figure/Table**   (general/\                                   Ballot Resolution
                                             technical/editorial)                         Meeting**
  ----------- ------------- ---------------- ---------------------- --------------------- -----------------------
  Expert      4                              Technical              Allow foreign         Accept. In Section 4,
                                                                    namespace elements    clearly state that
                                                                    and attributes        foreign elements and
                                                                                          attributes are removed
                                                                                          before validation.

  Expert      5\.                            Technical              Replace grammars with Accept in principle.
                                                                    frameworks, since     Use frameworks and
                                                                    RELAX NG already uses schemas instead of
                                                                    grammars.             grammars.

  Expert      6.1                            Technical              When the              Accept.
                                                                    targetNamespace       
                                                                    attribute of a module 
                                                                    is not specified but  
                                                                    the module is         
                                                                    referenced by another 
                                                                    module or framework,  
                                                                    inherit this          
                                                                    attribute from that   
                                                                    module or framework.  

  Expert      6.4 and 6.5                    Technical              Allow \<ref\> to      Accept. Change the
                                                                    follow \<attribute\>  content model as
                                                                    within \<tag\> and    follows:\
                                                                    \<attribute\>.        (annotation?, (ref \|
                                                                                          attribute)\*)

  Expert      7.2                            Technical              Explicitly state      Accept. Explicitly
                                                                    identity constraints  state identity
                                                                    of ID/IDREF/IDREFS,   constraints in 7.2.
                                                                    since XML Schema Part 
                                                                    2 no longer state     
                                                                    them                  

  Expert      7.2                            Technical              Specify which         Accept . Recommend
                                                                    datatypes and facets  datatypes string,
                                                                    are strongly          boolean, float, double,
                                                                    recommended.          anyURI,
                                                                                          normalizedString,
                                                                                          token, language,
                                                                                          NMTOKEN, NMTOKENS,
                                                                                          Name, NCName, ID,
                                                                                          IDREF, long, int,
                                                                                          short, byte,
                                                                                          unsingedLong,
                                                                                          unsingedInt,
                                                                                          unsingedShort,
                                                                                          unsingedByte. Also
                                                                                          recommend facets
                                                                                          length, minLength,
                                                                                          maxLength, enumeration,
                                                                                          maxInclusive,
                                                                                          maxExclusive,
                                                                                          minInclusive,
                                                                                          andminExclusive.
  ---------------------------------------------------------------------------------------------------------------