ISO/IEC JTC 1/SC34 N0389

 

 

ISO/IEC JTC 1/SC34

Information Technology --

Document Description and Processing Languages

 

Title:

Summary of Voting on JTC 1/SC 34 N 363 CD Ballot for 19757-4 - DSDL Part 4 - Selection of Validation Candidates

Source:

SC 34 Secretariat

Project:

19757-4 - DSDL Part 4

Project editors:

WG 1

Status:

 

Action:

Based on the ballot responses, this CD is approved to advance to FCD ballot.  Project Editors are requested to review comments and take them into consideration when preparing revised text.

Date:

26 March 2003

Summary:

 

Distribution:

SC34 and Liaisons

Refer to:

 

Supercedes:

 

Reply to:

Dr. James David Mason
(ISO/IEC JTC1/SC34 Chairman)
Y-12 National Security Complex
Information Technology Services
Bldg. 9113 M.S. 8208
Oak Ridge, TN 37831-8208 U.S.A.
Telephone: +1 865 574-6973
Facsimile: +1 865 574-1896
E-mail: mailto:[email protected]
http://www.y12.doe.gov/sgml/sc34/sc34oldhome.htm

Mrs. Sara Desautels, ISO/IEC JTC 1/SC 34 Secretariat
American National Standards Institute
25 West 43rd Street
New York, NY 10036
Tel: +1 212 642-4937
Fax: +1 212 840-2298
E-mail: [email protected]

 

SC 34 Voting Summary on JTC 1/SC 34 N 363 CD Ballot for 19757-4 - DSDL Part 4 - Selection of Validation Candidates

P-Member

APPROVAL OF THE DRAFT AS PRESENTED

APPROVAL OF THE DRAFT WITH COMMENTS AS GIVEN ON THE ATTACHED

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):

Brazil

 

 

 

 

 

Canada

X

 

 

 

 

China

X

 

 

 

 

Denmark

 

 

 

 

 

France

 

 

 

 

 

Ireland

 

 

 

 

 

Italy

X

 

 

 

 

Japan

 

X

(gen / tech)

 

 

 

Republic of  Korea

 

 

 

 

 

Netherlands

X

 

 

 

 

Norway

X

 

 

 

 

United Kingdom

 

 

X

X

 

United States

X

 

 

 

 

 

 

 

 

 

 

 

 

 

 

SC 34 National Body Comments on N 363

JAPAN Comments

1. General

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

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.

UK Comments

The text of the document submitted for vote is insufficiently complete for it to

be possible to assess its suitability as a Committee Draft. Without the syntax

and formal reference model we cannot make an adequate judgment on the text.

 

From the fragmentary text available for assessment it seems likely that the

overall technical approach being suggested for this Part of DSDL is too

simplistic. For example, the attribute selection process is too weak to consider

realistic. It only allows one attribute at a time to be used to identify fragments,

rather than sets of attributes. It does not allow the same attribute to be used to

select fragments based on the value assigned to the attribute. Also, there is

no mechanism for selecting fragments based on elements or element content.

 

A much more complete draft is needed for a proper judgment to be formed.