---

Summary

P-members to vote: 38

P-member votes cast (>=50%): 19 (50.0%)

Total votes cast: 12

P-member approvals (>=66%): 9 (75.0%)

Total disapprovals (<=25%): 3 (25.0%)

Detail

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
Bulgaria						X
Brazil						X
Canada			X
Switzerland	X
Côte-d'Ivoire						X
Chile						X
China						X
Colombia					X
Cyprus						X
Czech Republic			X
Germany		X
Denmark					X
Egypt						X
Finland					X
France					X
India	X
Italy	X
Japan				X
Kenya	X
Korea, Republic of						X
Kazakhstan						X
Lebanon						X
Sri Lanka						X
Malta					X
Netherlands					X
Norway	X
New Zealand						X
Pakistan						X
Poland						X
Romania	X
Sweden					X
Thailand						X
Turkey						X
Trinidad and Tobago						X
United Kingdom	X
USA	X
Venezuela						X
South Africa						X

Canada

1. Editorial, Inconsistent use of "element content"

The document sometime uses the phras "element content" and other times uses the phrase "element contents". All of these differences should be checked.

2. Minor Technical, Section 3 Terms and definitions

a) The definition for "entity" refers to ISO 8879:1986 but this standard is NOT in the normative references.

b) The definition for "entity node" refers to "Document Object Model" but his is not defined and there is no normative reference to the W3C DOM specification. Having the DOM specification in the Bibliography is not sufficient.

c) The definition of "IRI" refers to IETF RFC 2987. I believe the correct reference is to RFC 3987 which is in the normative references.

3. Minor Technical, Section 5 DSRL maps

This section fails to specific the semantics when the two optional attributes are BOTH missing.

4. Minor Technical, Section 6.1 Reassigning element and attribute names

The term "qualified name" is used without a definition.

5. Major Technical, Section 6.1 Resassiging element and attribute names

This section includes the text "No two dsrl:element-map elements shall have the same contents for both their dsrl:parent element and their dsrl:from element.". These is NO defintion of "same contents" provided. In particular does "same" mean just the "same syntax" or the "same semantics". For example if is possible to use different XPath syntaxes that have the same semantics.

6. Editorial, Section 6.1, Reassigning element and attribute names

The examples use http://www.mycompany.com. It is preferable to use a URI based on http://example.org.

7. Editorial, Section 6.1 Reassigning element and attribute names

There are several sentences in this section that are hard to understand since the English connective "then" is ommitted. For example, the sentence:

"If the dsrl:to element is empty the attributes named ..."

would be better worded as follows:

"If the dsrl:to element is empty, then the attributes named ..."

This construct could be used in MANY locations in this section and others to improve the readability of this specification.

8. Editorial, Section 6.1 Reassigning element and attribute names

The specification used different forms of references to the Normative References. For example sometimes is uses "W3C XML specification" and other times is uses just "XML specification". The referencing should be harmonized for ALL references.

9. Major Technical, Section 6.2 Mapping attribute values

This section includes the text "No two dsrl:from elements within the same dsrl:values-map element may have the same contents." These is NO defintion of "same contents" provided. In particular does "same" mean just the "same syntax" or the "same semantics". For example if is possible to use different XPath syntaxes that have the same semantics.

10. Editorial, Section 6.7 Mapping entity references

a) Change "for defining the equivalent" to "for defining the equivalence".

b) Change the "information set" to "the Information Set".

11. Editorial , Section 6.7 Mapping entity references

a) The term "referenced entity set" is not defined.

b) No references is given to define "W3C Document Object Model".

12. Editorial, Annex B

a) Change "taken for the following" to "taken from the following".

b) Change "to text the full range of options" to "to test the full range of options".

13. Minor Technical, Annex B

a) Remove the text "with a Saxon or other processor" since this text is not needed or appropriate.

14. Editorial, Annex B

a) Correct the grammar in "The processing model used to within the example application".

15. Major Technical, MIME type

This specification does not indicate what MIME type would be used for a DSRL resource.

16, Major Technical, Security considerations

This specification does not provide any "security considerations" that a user or implementor should be aware of when using this XML format. These might be provided as part of the appropriate MIME type definition.

Czech Republic

The Czech Republic`sobjections to the Second FCD 19757-8

1. page 3/§6.1: Definition of dsrl:from and dsrl:to elements uses non-standard mechanism for declaring namespaces prefixes:

If the content is a qualified name, the namespace used must be declared in a namespace declaration that is declared as an attribute of the dsrl:from element.

This definition is inconsistent with the XML namespaces where namespaces can be declared on element or any of its ancestors. According XML namespaces namespace declarations are inherited to all descendant elements (if not overwritten), but this FCD is considering only declarations present directly on dsrl:from/dsrl:to element. This is not only inconsistent, but it also makes DSRL harder to implement, because some XML data models or APIs are not exposing namespace declarations literally, they are exposing view of XML document where namespace declarations are already inherited. In this case it is impossible to distinguish situation where namespace was declared directly on dsrl:from/dsrl:to from situation where namespace was declared on ancestor of this element.

Declaration of namespaces should not be described in FCD and only reference to XML namespaces recommendation should be given.

2. page 3/§6.1: XPath locations are mentioned as a content of dsrl:parent element. But it would be more appropriate to use XPath patterns (as defined in http://www.w3.org/TR/xslt.html#patterns) only.

3. Section 7 "Declaring entities" on page 7 should be completely removed or at least made optional for the following reasons:

References between entities are not allowed which makes this mechanism even less powerful then entities mechanism provided by XML.

Markup inside replacement text is escaped (in this case using CDATA section) – so it is not markup anymore and can't be processed without reparsing as a separate document.

Mechanism for attaching entity definitions to document instance is not defined.

Editorial issues:

page 2/§3.3: "Document Object Model" is mentioned, but no reference to corresponding W3C specification is provided

page 2/§5: description of targetSchemaLocation attribute is not clear. Especially it is not clear what this attribute has to do with "the prefix assigned to the schema..."

Germany

General

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

We still believe that entities should be dropped entirely from this part, since entity renaming and redefinitions cannot be reliably implemented. If entities are supported as first-class objects by XML processors and data models in the future, entity renaming and redefinitions can be introduced again.