Vote on Committee Draft ISO/IEC JTC 1/SC 34 N 363
|
Date of circulation:
Closing date:
|
Reference number ISO/JTC 1/SC 34 N 363 |
|
ISO/JTC 1/SC
34 Document Description
and Processing Languages Secretariat: USA |
Circulated to P-members of the committee for voting Please return all votes and comments in electronic form directly to the SC 34 Secretariat by the due date indicated. |
|
ISO/IEC Title: Proposed CD text for
DSDL Part 4: Selection of Validation Candidates |
Vote:
|
_____ |
APPROVAL OF THE DRAFT AS PRESENTED |
|
__X__ |
APPROVAL OF THE DRAFT WITH COMMENTS AS GIVEN ON THE ATTACHED |
|
_X_ |
general: |
|
_X_ |
technical: |
|
___ |
editorial: |
|
_____ |
DISAPPROVAL OF THE DRAFT FOR REASONS ON THE ATTACHED |
|
___ |
Acceptance of these reasons and appropriate changes in the text will change our vote to approval |
|
_____ |
ABSTENTION (FOR REASONS BELOW): |
P-member voting:
__JAPAN___________________________
Date:
__2002-02-25______________________
Submitted by:
__Yushi KOMACHI___________________
We believe that MNS(Multiple Namespaces) from James Clark is an important contribution. We propose to make Part 4 independent from Part 1. That is, it should be possible to use Part 4 without using Part 1, just like we can use Part 2 without using Part 1. This independence is consistent with the spirit of DSDL.
2.1 Isses listed in the CD >Issue 1: Should we drop attribute-based selection (4.2)? We do not see any requirements for attribute-based selection. We propose to drop attribute-based selection from Part 4. >Issue 2: Is the design of attribute-based selection powerful enough? Drop attribute-based selection. >Issue 3: Should we unify namespace-based selection (4.1) and >attribute-based selection (4.2)? Drop attribute-based selection. >Issue 4: Should we allow attributes as validation candidates? In >other words, should we detach attributes from elements? This might be >useful for allowing common attributes. Allow attributes as validation candidates and use MNS as a basis. It might make sense to validate attributes from multiple namespaces together. >Issue 5: Should we introduce an additional constraint that applies to >the validation candidate representing the document root? We believe that such constraints on root elements are strongly required. However, in our opinion, this is just one example of fragment interaction. For example, we might want to allow XHTML paragraphs in CALS tables but disallow XHTML root elements in CALS tables. Issue 5 is an interaction between the document root and the root element. When individual schemas are open and can be slightly modified, we can easily represent constraints on such interactions. Ideally, such modifications should be provided by the overriding feature of <include> of RELAX NG. When individual schemas are closed or they cannot be modified at all, it is not easy to capture such constraints. The context feature of MNS is an interesting attempt, but we are not sure if it hits an 80/20 point. >Issue 6: Should we introduce an additional attribute of dummy to >represent the tag name of the original element? This is an attempt to capture more constraints on fragmment interaction (see Issue 8). Although this extension is ad-hoc, we feel that it hits an 80/20 point. >Issue 7: Should we use foreign elements rather than dummy elements? Yes, s/dummy/foreign/g. >Issue 8: Should we duplicate subtrees rather than extracting them? In >other words, should we keep original elements rather than replacing >them with dummy elements? MNS suggest another option, which is to delete original elements. Among the three options, which one should DSDL part 4 adopt? Here are some observations, which hopefully help discussion at SC 34. An advantage of the keep option is that we can use open schemas without changing them. Another advantage is that, if we slightly modify individual schemas, can easily captrue constraints on fragmment interaction. Meanwhile, a disadvantage is that it requires duplication of validation, thus making validation slow. The delete option has a similar advantage: we can use closed schemas without changing them. However, this option does not allow individual schemas to represent constraints on fragmment interaction. An advantage of the dummy option is that it avoids duplication of entire subtrees but can still capture some constraints on fragmment interaction. A disadvantage is that it mandates changes in individual schemas. >Issue 9: Should extracted fragments inherit XML version numbers? We do not see any requirements for this feature. >Issue 10: Should extracted fragments inherit namespace declarations? Part 4 should use the data model of Part 2, which expands namespace declarations and remove comments and PIs. Then, fragments will inherit namespace declarations. >Issue 11: Should extracted fragments inherit xml:lang, xml:base, and >other such attributes? We believe that attribute inheritance is outside the scope of validation. We thus propose not to introduce such inheritance. >Issue 12: Should we allow foreign-namespace elements and attributes >(annotations) as does RELAX NG? DSDL part 4 should allow annotation elements and attributes. A normative schema for XML representations of DSDL Part 4 should use DSDL Part 4 for representing such annotations. >Issue 13: Should we allow the VSCL root element to have a version >attribute indicating the version of DSDL VSCL? Introduce an attribute similar to Part 2. >Issue 14: Which namespace URI is appropriate for DSDL VCSL? We do not have any comments. >Issue 15: Which namespace URI is appropriate for dummy nodes? At >present, http://www.xml.gr.jp/xmlns/dummy is used. We do not have any comments. 2.2 Others 1) <include> We propose to introduce <include>, which is similar to <include> of Part 2. The overriding feature of <include> allows easy modifications of VCSL descriptions. 2) embedding of individual schemas We propose to allow VCSL descriptions to directly contain schmas. This feature is particularly useful, when we have to slightly adjust existing schemas.
Reply to: Sara Desautels, Secretariat, ISO/IEC JTC 1/SC
34, ANSI, 25 West 43rd St , New York, NY 10036
Telephone:
212-642-4937; Facsimile: 212-840-2298; E-Mail:
sdesaute@ansi.org