---

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	DISAPPROVAL (appropriate changes in the text will change vote to APPROVAL)	ABSTENTION (For Reasons Below)	NO RESPONSE
Canada	X
Switzerland					X
China	X
Germany		X
Denmark						X
India						X
Italy	X
Japan				X
Korea, Republic of						X
Kazakhstan						X
Netherlands					X
Norway	X
Thailand						X
United Kingdom	X
USA	X

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.