ISO/IEC JTC 1/SC 34N0817

ISO/IEC JTC 1/SC 34

Information Technology --
Document Description and Processing Languages

TITLE:	Summary of Voting on JTC 1/SC 34 N 792 - Text for FCD ballot for ISO/IEC 19757-8: Document Schema Definition Language (DSDL) Part 8 - Document Schema Renaming Language (DSRL)
SOURCE:	SC34 Secretariat
PROJECT:	FCD 19757-8: Information technology - Document Schema Definition Languages (DSDL) - Part 8: Document Schema Renaming Language (DSRL)
PROJECT EDITOR:	Mr. Martin Bryan
STATUS:	Summary of voting
ACTION:	Based on the ballot responses, this FCD is APPROVED and the project status changes to 40.60. Project Editors are strongly urged to review negative comments and advise the Secretariat regarding (1) the change to status 40.92, 40.93 or 40.99, and (2) the next project status and anticipated date that project status will change.
DATE:	2007-02-22
DISTRIBUTION:	SC34 and Liaisons
REFER TO:	N0792b - 2006-10-17 - Ballot due 2007-02-17 FCD 19757-8: Document Schema Definition Language (DSDL) Part 8 - Document Schema Renaming Language (DSRL) N0792 - 2006-10-17 - Text for FCD ballot for ISO/IEC 19757-8: Document Schema Definition Language (DSDL) Part 8 - Document Schema Renaming Language (DSRL)
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

Germany

Multiple reference is on IRI "…purl.oclc.org/…" and its underlying namespace. The namespace should comply with that from the other parts of ISO/IEC 19757, especially Part 2.

Japan

1. Major comments

Japan will change the vote to approval, if the major comments (shown below) are satisfactorily resolved.

1.1 Clarify the scope

What should be introduced in this standard? The current draft introduces renaming of elements, attributes, attribute values, entities, and PI targets. These renaming features are certainly sensible, as suggested by the name of this part.

However, this draft further introduces other features. They are default values (even forced default values) of attributes, default contents of elements, and entity definitions. These features are highly questionable.

On the other hand, there are no mechanisms for reordering of elements, converting attributes to elements (and vice versa), or functions manipulating strings or numbers. One could certainly argue that default values are irrelevant to renaming, but these features are closely related with renaming. For example, to interpret
     <name><first>Makoto</first><last>Murata</last></name>
and
     <fahrenheit>100</fahrenheit>
as
     <namae><sei>MURATA<sei><mei>MAKOTO</mei></namae>
and
     <centigrade>30</centigrade>
we have to reorder elements and apply numeric functions.

We understand that XSLT, XQuery, and other or other transformation languages are already available, and that we should not try to introduce all features of such languages to this part. However, if important features mentioned above are omitted, why should default values and default contents be introduced in this part?

1.2 Introduce a processing model

The current text does not provide processing models. The lack of processing models causes two problems. First, the semantics of DSRL is not very clear. For example, is DSRL implemented as part of XML processors, or is it implemented as a thin layer on top of XML processors? What is an input and output of DSRL implementations? Second, it is not clear whether DSRL can be built on top of conformant XML processors as defined in XML 1.0. We believe that this is impossible.

1.3 Drop entity definitions

We strongly propose to drop entity definitions. First, entity definitions are irrelevant to renaming. Second, since XML processors as defined in XML 1.0 do not use DSRL entity definitions, it is impossible to build DSRL-conformant implementations using XML processors.

2. Minor comments

2.1 Allow value-maps for elements

At present, they are allowed for attributes only. We do not see any reasons for disallowing them for elements.

2.2 Introduce precedence rules

When more than one element-map is applicable to a single element, which one is used? When more than one attribute-map (which may be global or local) is applicable to a single attribute, which one is used?

2.3 Use datatypes in schemas

In the normative RELAX NG schema for DSRL, "text" is used several times. However, xsd:QName is often more appropriate.

2.4 Name token groups

We do not understand the first sentence of 6.2. In particular, what do gname token groupsh mean? Please clarify.

2.5 Drop default values and default contents

As shown in the first major comment, we believe that default values and default contents are outside the scope of this part.