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