ISO/IEC JTC 1/SC34 N415

JTC1 Logo

ISO/IEC JTC 1/SC34

Information Technology --

Document Description and Processing Languages

TITLE: Comment disposition of JTC 1/SC 34 N 363 CD Ballot for 19757-4 - DSDL Part 4 - Selection of Validation , London, 3–4 May 2003
SOURCE: SC34/WG1
PROJECT: 19757-4 - DSDL Part 4
PROJECT EDITOR: MURATA Makoto [FAMILY Given]
STATUS:
ACTION: Based on the comment disposition, Project Editors are requested to create a text for the FCD
DATE: 7 May 2003
DISTRIBUTION: SC34 and Liaisons
REFER TO:
SUPERSEDES:
REPLY TO: Dr. James David Mason
(ISO/IEC JTC1/SC34 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-18964
Network: masonjd@y12.doe.gov
http://www.y12.doe.gov/sgml/sc34/
ftp://ftp.y12.doe.gov/pub/sgml/sc34/

Ms. Sara Hafele, ISO/IEC JTC 1/SC 34 Secretariat
American National Standards Institute
11 West 42nd Street
New York, NY 10036
Tel: +1 212 642 4976
Fax: +1 212 840 2298
Email: shafele@ansi.org

1. Japan

1) Consider MNS

Accept in general. See the disposition of other comments.

2) Make Part 4 independent from Part 1

Accept in principle, but note that the word "independent" is unclear.

It should be possible to use Part 4 without using part 10, and it should also be possible to use Part 4 from within Part 10.

3) Drop attribute-based selection

Accept.

Note that patterns in RELAX NG can easily capture interdependencies between attributes and elements. If this feature is not sufficient, national member bodies are invited to provide use cases and raise this issue again.

4) Allow attributes as validation candidates as does MNS

Accept.

5) When constructing validation candidates for attributes, combine those attributes belonging to the same namespace.

Accept (the same as in MNS).

6) Introduce constraints on the top-level validation candidate.

Reject. The reserved mode #default captures this constraint. Moreover, the proposed mechanism is a special case of MNS's contexts.

7) Do not introduce contexts for now.

Reject. Contexts are useful for handling closed schemas. However, add a note about concerns as follows:

8) s/dummy/foreign/g

Reject. Use "external".

9) keep (MNS), foreign (CD), prune (MNS), and depth-interleaved(Switchboard)

Another option [JAPAN] is to keep foreign elements but prune their attributes and contents. We agreed that we introduce this option as well as "keep" and "prune".

However, we agreed not to introduce the option "depth-interleaved" for now, but add a note about this option. Although the option "depth-interleaved" is interesting, no schemas use it and no implementations support it as of now.

We agreed that we do not introduce the option "external". However, we agreed to add a note about this option.

Yet another option was suggested by Eric van der Vlist. This option copies the parent element of a validation candidate and attach the copied element as the root of the validation candidate. We agreed that we do not introduce this option but add a note about it.

For each option, the editor is instructed to add illustrative diagrams and notes about its advantages and disadvantages.

10) Introduce an additional attribute of "external" to represent the tag name of the original element.

Reject. This mechanism is ad-hoc and cannot be generalized to attributes.

11) Use the data model of DSDL Part 2

Accept.

12) Do not introduce inheritance of xml:lang, xml:base, etc.

Although this inheritance may capture some interdependencies of xml:base and attributes specifying relative URIs, we agreed not to introduce such inheritance in the FCD. First, there are quite a few inherited attributes that do not belong to the namespace for the prefix "xml". Thus, we do not know all of the attributes that should be copied. Second, it is always possible to create a monolithic schema which captures such interdependencies by not using Part 4.

National member bodies may raise this issue again in the next ballot, but are requested to provide motivating examples.

We also discussed XML Versions. Should each validation candidate "inherit" XML versions? We agreed that we do not introduce this "inheritance".

13) Allow foreign-namespace elements and attributes (annotations) in VCSL schemas.

Accept.

14) Use VCSL for describing the schema for VCSL Schemas

Accept. But we agreed to create another schema in RELAX NG so that readers can compare the two descriptions.

15) Introduce an attribute representing the version of DSDL Part 4.

Reject. As in RELAX NG, use a versioned namespace name.

16) Add <include>, which is similar to <include> of Part 2

Accept. As in RELAX NG, <include> merely merges the contents of two Part 4 schemas. Moreover, child <validate> or <validateAttributes> of <include> override those <validate> or <validateAttributes> in the referenced schema, when they specify the same namespace set and modes.

17) Allow Part 4 schemas to directly contain other schemas.

Accept. Add an element "schema" having a schema as its content.

2. MNS

1) Introduce cover

Accept.

2) Introduce lax

Accept in principle. However, if we allow infinite namespace sets and introduce a default schema that accepts anything, we might not need <lax> elements. The editor is instructed to compare these two approaches and create a proposal for this FCD.

3) Introduce an attribute for specifying the schema language by a media type, since non-XML schemas do not have namespace URIs

We agreed to use file name extensions such as rnc, rng, dtd, xsd, and other extensions defined by the other parts of this standard.

We agreed to add a note about supplementary mechanisms such as media types, notations, and URIs.

4) Introduce modes

Accept. However, block scoping of namespaces, as proposed in Namespace Switchboard, appear to have similar descriptive power. The editor is instructed to compare these two mechanisms and create a proposal for this FCD.

5) Should there be separate sets of namespaces that cover elements and cover attributes?

Add an editorial note and wait for feedback from users.

6) Allow descriptions of infinite sets of namespaces

Use nameclasses of Part 2 as a basis. However, introduce some mechanism for representing not-mentioned namespaces easily. The editor is instructed to provide a complete text.

Add a note about: Do we want to specify "any namespace beginning with http://example.com/"?

3. UK

1) The text of the document submitted for vote is insufficiently complete.

Accept. Fortunately, we have a number of substantial inputs (MNS, Namespace Switchboard, etc.) and a DTR for RELAX Namespace. Based on them, the editor is instructed to provide a more complete draft.

2) The overall technical approach being suggested for this Part of DSDL is too simplistic.

Accept. Based on the disposition of the other comments, the project editor is instructed to make a non-simplistic FCD.

3) The attribute selection process should be more powerful

Please provide a motivating example. See the disposition of Japan-3.

4. Namespace Switchboard (Rick)

1) Use "namespace" (non-procedural) rather than "validate" (procedural).

We propose the use of the term "select".

2) Use "rule" rather than "rules"

We propose the use of the term "selections".

3) copes with depth-interleaved namespaces

See the disposition of Japan-9.

4) Adds support for namespace and schema versions

Reject for now. This feature might belong to (A) each schema language, (B) Part 8 (Declarative Document Architecture), or (C) a simple program which converts a schema to another. In particular, qualified names in attribute values cannot be handled by Part 4.

5) limits modes and context, which belong in schema languages themselves,

See the deposition of Japan-4, Japan-7, and NamespaceSwitchboard-8.

6) Introduce a mechanism for representing validation results

Reject. If we provide a standard mechanism, we tie the hands of implementers by disallowing error handlers.

Note: Although lack of standard mechanisms for representing validation results may cause integration problems, we do not see any solutions.

7) Separate subtree extraction and traversal.

It has been implicitly assumed that RELAX Namespace, the CD, and MNS can be implemented using a streaming algorithm without changing validators for other parts. The editor is instructed to make this assumption explicit in the FCD.

8) Introduce block scoping of namespaces

Accept. However, modes of MNS appear to have similar descriptive power. The editor is instructed to compare these two mechanisms and create a proposal for this FCD.

5. Editor's comments

1) Disallow overlaps

If two <validate> elements are from the same namespace (note. we are talking about "ns" but not "cover"), their modes have to be different. This constraint is needed since we do not want to have two schemas for a single namespace. ASK James.

2) Namespace URIs

We need to investigate a permanent URI. It should be derived from http://dsdl.org/part4/1.0/.... to give something like purl://dsdl.org/part4/......

3) What about identifiers?

Since an individual schema does not always cover the entire document, Part 4 may cause identifier collision between different validation candidates. It was agreed that this issue should be handled by path-based integrity constraints, rule-based integrity constraints, or application programs. However, the editor is instructed to add a note about the possibility of identifier collision.

4) What should be the name of this part?

DSDL Part 4: Selection of Validation Candidates

An acronym is DSDL-VC.

5) Are we happy with the tag/attribute names of MNS?

The editor is instructed to find appropriate names. UK suggested that "covers" is better than "cover". UK also suggested that "selections" and "select" are better than "rules" and "validate".