[OASIS Issue Tracker] Commented: (OFFICE-3440) ODF 1.2 CD05 Part 1Needs anyIRI datatype

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ http://tools.oasis-open.org/issues/browse/OFFICE-3440?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=22346#action_22346 ] 

Michael Brauer commented on OFFICE-3440:
----------------------------------------

Dennis, it is still not clear to me what exactly you would like to achieve by your proposal, or why you object to the other options. Sine no one else commented so far, maybe it helps if we look at the individual pieces of your proposal:

1. Everywhere that the datatype anyURI is used in the ODF 1.2 schema, replace it with anyIRI. 
"anyURI" in the schema is just a define. We may rename it to "anyIRI" if we like or consider this to be useful. We may also stay with "anyURI" and provide a different definition. So, it's really just name. I have a slight preference however for staying with anyURI as long as we do provide a significant different definition than that of the W3C anyURI datatype. And I'm reluctant to change names in the last minute unless that is really technical required or solves a defect. But the name of the datatype is not the reason I've object to you proposal.
-0
2. Define anyIRI as a datatype based on anyURI but restricted so that no U+0000 to U+007F code points excluded in [RFC3987] are allowed. 
We may of course restrict some characters from the definition of anyURI that are not allowed in IRIs. My view on that however is somehow pragmatic. The W3C has refined the definition of anyURI based on RFC3987 for XSD 1.1. They have abstained from adding these restrictions. I consider them to be experts on the topic of datatypes. If they haven''t added this restriction, why should we? The W3C actually provided the reason why they haven't added this restriction. Even though this makes my comment longer, I repeat it here: Citation From the XSD 1.1 anyURI definition:
"Each URI scheme imposes specialized syntax rules for URIs in that scheme, including restrictions on the syntax of allowed fragment identifiers. Because it is impractical for processors to check that a value is a context-appropriate URI reference, neither the syntactic constraints defined by the definitions of individual schemes nor the generic syntactic constraints defined by [RFC 3987] and [RFC 3986] and their successors are part of this datatype as defined here. Applications which depend on anyURI values being legal according to the rules of the relevant specifications should make arrangements to check values against the appropriate definitions of IRI, URI, and specific schemes." 
That sound reasonable to me. There is not much value in adding some constrains if there are many others that cannot be checked as well. And who guarantees that a successor of RFC3987 does not permit any of the characters that you intent to forbid? 
So, for this one:
-0.5
3a. Adding [XPointer] as a normative reference. 
Your proposal does not reference [XPointer] at all. Why should we add a normative reference to it?
0
3b. Adding a reference to [RFC3987]
That sounds reasonable to me, but we need to know where exatly.
+1
4a. Definition of the anyURI datatype (with the exception of the notes)
My main concern here is the statement: "A valid anyIRI value is an anyURI value that conforms to the definition of IRI reference in [RFC3987]." This statement means that conforming ODF documents must contain only valid IRI values. That doesn't sound bad at the first glance, but if you look at the note that the W3C provided, then this says that it is impractical to checker whether IRI values are valid or not. I second that statement. By using that definition, we add normative clause that cannot be checked in practice. For that reason, my vote on your proposal is
-1
In addition I would like to repeat what I said for 2. here: I consider the W3C to be expert on the definition of datatypes. Why should their definition, that is used by many standards, whould not work for ODF? Why should ODF go its extra way here? What do we win by that?
4b. I have no strong opinion on the remainder of the anyIRI definition you propose, but consider this to be more notes than normative statements. We certainly can discuss whether we want to add parts of that as notes. 
0
4c. The notes: These mainly describe encoding practices. I don't think we need these in ODF specification,  and in particular those regarding encoding in XML seem to be too obvious to me. But, well, we certainly can discuss the one or the other note as well.
0

> ODF 1.2 CD05 Part 1 Needs anyIRI datatype
> -----------------------------------------
>
>                 Key: OFFICE-3440
>                 URL: http://tools.oasis-open.org/issues/browse/OFFICE-3440
>             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
>          Issue Type: Sub-task
>          Components: Needs Discussion, Part 1 (Schema), Schema and Datatypes
>    Affects Versions: ODF 1.2 CD 05
>            Reporter: Dennis Hamilton
>             Fix For: ODF 1.2 CD 06
>
>
> The rules for IRI references are slightly different than the rules for anyURI.  In particular, anyURI accepts ASCII characters that are excluded from IRI references by [RFC3987].
> Rather than qualify the use of anyURI to be specific to IRIs every place that anyURI is used in the current schema, it is recommended that this be handled in one place by introducing an anyIRI datatype that is  derivative of anyURI with an additional pattern constraint that eliminates the ASCII-corresponding characters that are excluded from IRI references in [RFC3987].

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira