ISO/IEC JTC 1/SC 34N0937
ISO/IEC JTC 1/SC 34
Information Technology --
Document Description and Processing Languages
|TITLE:||Summary of Voting on JTC 1/SC 34 N 894 - Text for Second FCD ballot for ISO/IEC 19757-8: Document Schema Definition Language (DSDL) Part 8 - Document Schema Renaming Language (DSRL)|
|PROJECT:||Second FCD 19757-8: Information technology - Document Schema Definition Languages (DSDL) - Part 8: Document Semantics Renaming Language (DSRL)|
|PROJECT EDITOR:||Mr. Martin Bryan|
|STATUS:||Summary of voting|
|ACTION:||Based on the ballot responses, this CD is APPROVED and the project status changes to 40.60. Project Editors are requested to review all comments and advise the Secretariat regarding (1) the change to status 40.92 or 40.99, and (2) the next project status and anticipated date that project status will change.|
|DISTRIBUTION:||SC34 and Liaisons|
|REFER TO:||N0894b - 2007-07-16 - Ballot due 2007-11-16 Second FCD 19757-8: Document Schema Definition Language (DSDL) Part 8 - Document
Schema Renaming Language (DSRL)
N0894 - 2007-07-16 - Text for Second FCD ballot for ISO/IEC 19757-8: Document Schema Definition Language (DSDL) Part 8 - Document Schema Renaming Language (DSRL)
Dr. James David Mason
(ISO/IEC JTC 1/SC 34 Secretariat - Standards Council of Canada)
Crane Softwrights Ltd.
Kars, ON K0A-2E0 CANADA
Telephone: +1 613 489-0999
Facsimile: +1 613 489-0995
Network: [email protected]
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%)
|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|
|Korea, Republic of||X|
|Trinidad and Tobago||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
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.
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..."
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.