ISO/IEC JTC 1/SC 34N0547

ISO/IEC logo

ISO/IEC JTC 1/SC 34

Information Technology --
Document Description and Processing Languages

TITLE: Comment Disposition for the voting on JTC 1/SC 34 N 525 - Document Schema Definition Language (DSDL) - Part 4: Namespace-based Validation Dispatching Language (NVDL)
SOURCE: Mr. MURATA Makoto [FAMILY Given]
PROJECT: CD 19757-4: Document Schema Definition Language (DSDL) Part 4 - Namespace-based Validation Dispatching Language
PROJECT EDITOR: Mr. MURATA Makoto [FAMILY Given]
STATUS: Disposition of Comments
ACTION: The editor is instructed to create FCD text.
DATE: 2004-10-10
DISTRIBUTION: SC34 and Liaisons
REFER TO: N0542 - 2004-09-14 - UK's comments on SC34 Ballot N525: Document Schema Definition Language (DSDL) - Part 4: Namespace-based Validation Dispatching Language (NVDL)
N0539 - 2004-09-10 - Summary of Voting on JTC 1/SC 34 N 525 - Document Schema Definition Language (DSDL) - Part 4: Namespace-based Validation Dispatching Language (NVDL)
N0525 - 2004-06-01 - Document Schema Definition Language (DSDL) - Part 4: Namespace-based Validation Dispatching Language (NVDL)
REPLY TO:

Dr. James David Mason
(ISO/IEC JTC 1/SC 34 Chairman)
Y-12 National Security Complex
Bldg. 9113, M.S. 8208
Oak Ridge, TN 37831-8208 U.S.A.
Telephone: +1 865 574-6973
Facsimile: +1 865 574-1896
Network: masonjd@y12.doe.gov
http://www.y12.doe.gov/sgml/sc34/
ftp://ftp.y12.doe.gov/pub/sgml/sc34/

Mr. G. Ken Holman
(ISO/IEC JTC 1/SC 34 Secretariat - Standards Council of Canada)
Crane Softwrights Ltd.
Box 266,
Kars, ON K0A-2E0 CANADA
Telephone: +1 613 489-0999
Facsimile: +1 613 489-0995
Network: jtc1sc34@scc.ca
http://www.jtc1sc34.org



Comment Disposition for the 2nd CD ballot of DSDL Part 4

ISO/IEC JTC1 SC34 WG1

2004 October

UK CommentsDisposition

Compact forms of the schemas, based on the current PDAM to 19757-2, should be added to the document. These should either be added at the start of Annex A and Annex B, or be included in clauses 6.2 and 6.3 in place of the current list of elements.

Accept. Add a RNC schema in clauses 6.2 and 6.3 in place of the current list of elements.

The distinction between the use of the hyphenated form of RELAX-NG to identify references to the standard itself and the unhyphenated form of RELAX NG used to refer to features of the standard should be dropped as confusing. Adopt one of the acronyms and use it in all instances.

Accept. Always use the unhyphenated form.

Resolve all comments made in Notes and remove the Notes.

Accept. Dispositions of other comments should resolve all comments made in Notes.

Introduction The last paragraph should be removed as it is not in keeping with ISO's style for introductions.

Accept. The origin of this part (the second sentence) is not removed, but the other sentences, which explain what has happened in SC34, should be removed.

2. Normative References Remove angle brackets from around URLs as this is not standard industry practice and is confusing as it appears to be a form of markup.

Accept. Drop "<" and ">".

3. Terms and definitions Order entries alphabetically so that people can find them easily while reading the text.

Accept.

Replace all terms already defined in Part 2 of the standard with a reference that states that terms defined in Part 2 also apply to this part. Alternatively, put all borrowed terms at the front of the list and add a line stating "Terms defined in this standard are: in front of the first term that is unique to Part 4.

Accept the 2nd proposal. That is, list all terms borrowed from Part 2 without defining them.

3.19 Change "of" to "for".

Accept.

3.36 Add at end "within an NVDL script".

Accept.

5.1 General In para preceding note 1, change "descendent element of e." to "descendent element of e'."

Accept.

5.2 - EXAMPLE 1 Insert space after "ns2 to" immediately before following URL.

Accept.

6.2 - Note and 6.3 - Note Change "consisting NVDL scripts" to "of" and "as below" to "shown below".

Accept.

Remove additional linespaces from list, if list not replaced by RNC representation of schema as suggested in General Comments.

A RNC schema replaces this list.

6.4.2 Annotations It is not clear how "qualified attributes" can "belong to descendent elements of schema elements". It is therefore unclear under what circumstances qualified attributes should not be removed. A clearer explanation of the fist line is required. What does the term "subordinate to schema elements" mean?

Accept. Here "schema" is used as the element name "schema" rather than a generic term, but this word is not formatted as such.

In the note, change "[base URI]" to "base URI".

Use "the [base URI] property".

6.4.10 In heading, and throughout the text, change "in validate" to "within validate". In second paragraph, change "is moved as" to "becomes".

Accept.

6.4.11 Change "of it" to "of the element".

Accept.

6.4.12 In third paragraph, insert a comma after "mode" and a colon after "sequence".

Delete the comma after "mode" and a colon after "sequence".

7.3 EXAMPLE Change "EXAMPLE 2" to "Example 2" for consistency with style developed in 7.2

Accept.

Point out that example is incorrect so will generate an error and/or add/reference an example where no error will be generated.

Move the last sentence of the first paragraph after the example and another example explaining the last sentence.

7.4 EXAMPLE1 and EXAMPLE2 Insert space before number in heading used for both examples

Accept.

Change "EXAMPLE 1" to "Example 1" in both examples.

Accept.

7.5 EXAMPLE Change "EXAMPLE" to "Example"

Accept.

8.3 In first paragraph change "NDVL" to "NVDL".

Accept.

In first list item change "comprising" to "which contains".

Accept.

8.7 In second list item change "term" to "time".

Accept.

In NOTE 1 insert space after "for".

Accept. Also insert space fter "application/xml".

C.1 Change "specified in 6.4.2" to "indicated in the Note in 6.4.2". [NB. Notes are informative: therefore what is stated in them is not "specified", only "indicated".]

Withdrawn. See the disposition for 6.4.2.

Change "in6.2" to "in Annex A" or, if the RNC is included in the note in 6.2 to "the note in 6.2".

Accept.

D.2.2.6 Change "xforms.rng" to "xhtml.rng".

Accept.

Japanese CommentsDisposition

(1.1) Since this part is based on a fast-track DTR submitted from Japan, we request that this part be freely available.

WG1 recommends that SC34 should ask JTC1 to make the final text freely available as the document is based on a fast-tracked Japanese standard that is publicly available, which has previously been circulated as Part 2 of ISO/IEC 22250.

(2.1) The combination of XML 1.1 and Namespaces 1.1 should be allowed.

Reject. At present, RELAX NG schemas never allow XML-1.1-but-not-XML-1.0 name characters. Thus, even if NVDL allows XML 1.1 and Namespaces 1.1, NVDL schemas (which are very likely to use RELAX NG) will not allow XML-1.1-but-not-XML-1.0 name characters. Thus, the only advantage of using XML 1.1 and Namespaces 1.1 is (1) C0 control functions and (2) #x85 and #x2028 as end-of-line characters. It is believed that XML 1.1 and Namespaces 1.1 should be addressed when the entire DSDL family can address them.

(2.2) It should be possible to create multiple element sections from a single-namespace document. This allows the use of NVDL for large single-namespace vocabularies (e.g., DocBook or CALS). We propose to introduce <trigger> elements as children of the <rules> element.

    <rules>
      <trigger ns="..."
             name="...."/>
      <trigger ns="..."
             name="...."/>
        ...
      <mode...>
        ...
      </mode>

      ...
    </rules>

Accept. The project editor is instructed to provide the details. A mechanims for inheriting the the "ns" attribute is expected to be incorporated.

(2.3) Improve "mode inclusion" on the basis of multiple inheritance in programming languages.

Accept.

Case 1: upper-level modes do not override

"namespace" or "anyNamespace" elements in lower-level modes will be used. If two "namespace" elements in lower-level (sibling) modes compete, we have a syntax error.

Case 2: when upper-level modes override by specifying actions other than "cancelNestedActions"

"namespace" or "anyNamespace" elements in upper-level modes will be used and those in lower-level modes will not be used.

Case 3: upper-level modes override by specifying "cancelNestedActions"

"namespace" or "anyNamespace" elements in upper-level modes will not be used and those in lower-level modes will not be used.

(2.4) Introduce schema rewriting for those RELAX NG schemas which are referenced from validate actions applied to attribute sections.

Accept. This part of the standard introduces schema rewriting for RELAX NG. Other schema languages shall provide rewriting (or wrapping) mechanisms, if they interact with NVDL. If they do not, schema authors have to specify "virtualElement" explicitly. The project editor is instructed to propose an appropriate namespace for "virtualElement".

(2.5) The semantics of path expression matching should be clearly defined.

Accept.

(2.6) Introduce the dummy and root-only option.

Introduce the "dummy" action, since this option is expected to be useful for data binding. The project editor is instructed to provide the details.

(2.7) Register a media type for the RELAX NG compact syntax at IANA and mention it in this standard.

If a media type for the RELAX NG compact syntax is registered at IANA, mention the media type in a Note.

(3.1) Section 7.7 (invoking non-NVDL validators) should be deleted, since we already have Section 8.7.

Accept, but everything important should be moved to 8.7.

(3.2) In 6.4.12 (mode inclusion), clearly state that the use of XInclude or parsed entities is intended for syntactical inclusion and that "mode inclusion" provides post-processing after syntactical inclusion.

Accept. Mention this assumption in a Note.

(3.3) In Section 8, a new subsection is needed for explaining the creation of sections from instances. This section should refer to 5.2.

Accept. Insert a subsection before 8.3 Stage 1.

(3.4) Options have problems as below:

  1. It is impossible for this part to specify options for all schema languages,
  2. Different implementations of one schema language may provide different options, and
  3. The syntax of options might be more complicated than name-value pairs. To overcome these problems, we propose to make the syntax and semantics of options entirely implementation-dependent.

Standardize a bit (option, @mustSupport, @arg, @name) and clearly state that the rest is implementation dependent. The project editor is instructed to provide the details.