OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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

Michael Brauer commented on OFFICE-3440:

Okay. But what issue does it resolve? 

Is it that the lexical representation of anyURI allows some character not allowed in IRIs? 

In that case I still recommend that we take the note in the XSD 1.1 specification very serious, which says: "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.". (A similar note can be found in the XSD 1.0 specification). So, yes, the lexical representation is not as restrictive as IRIs are, but there are very good reasons for this. 

Is it that a note is missing that anyURI is not as restrictive as IRIs are?

In that case, we can easily resolve the issue by adding the note that XSD 1.1 contains: "Note: 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."
We don't need a new datatype definition for this.

Or is it that there are URIs that are not valid IRIs?
I don't think this is the case, but if so, we certainly don't want to forbid these URIs. The right solution then would be to talk about "URIs and IRIs" where we currently talk about IRIs only.

The reason I'm reluctant to change the definition of the datatype simply is that it would be worse if we (unintentionally) forbid some URIs or IRIs only because we want to be better than the XSD specification. Our anyURI datatype is the XSD datatype for 5 years now, and we did not have any difficulties with that. We in my opinion should not change the datatype definition in the current phase of ODF 1.2 to a definition with which we have no experience.

> 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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]