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-3342) NEEDS-DISCUSSION:ODF 1.2 Part 1 "IRI" abuse

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

Dennis Hamilton commented on OFFICE-3342:

I was off base.

Here is the situation:

1. The set of valid URIs is a subset of the valid IRIs.

 2. There is a mapping by which IRIs that are not URIs can be transformed into valid URIs.

 3. AN IRI IS NOT AUTOMATICALLY AVAILABLE TO USE ANYWHERE THAT A URI IS EXPECTED.  For example, [xml-names] does not support IRIs as namespace URIs (though there is no such restriction on the prefix, if any the namespace is bound to and the local names, all of which can be general XML NCNames.  There is a corresponding interdependency with the various usages of URIs in RDF.

 4. The use of the transformed URI in place of the non-URI IRI is acceptable anywhere that a URI is accepted, unless there are additional restrictions that prevent the particular case.  However, it is misleading to say that IRIs are being allowed.  IRIs that are not URIs are not being allowed and this needs to be clear in how we described the situation and what we call such URIs.

  5. IRI REFERENCES ARE PERMITTED DIRECTLY IN THE LEXICAL FORMS OF THE XML SCHEMA anyURI DATATYPE.  IRI References are also permitted directly in the lexical forms of xlink:href attribute values (with some special rules for fragment identifiers).


  6. IT IS NECESSARY that any IRI Reference value BE CONVERTIBLE to a pure URI reference using procedures specified by the W3C for anyURI and xlink:href. 

  7. IT IS NECESSARY TO SAY WHEN any IRI Reference is converted to a URI Reference for resolution purposes.  This last probably impacts only Part 3 where resolution of Relative IRI references against manifest:full-path values (and related Zip directory file names) is required.

  8. To assure unambiguous conversion to and from a URI [Reference]s and unambiguous comparison of URI segments with segments in manifest:full-path values, it is desirable to minimize the use of %-encoding in IRIs themselves.  One way is to never %-encode the single-byte character codes of those US-ASCII characters that don't have to be %-encoded in a URI segment and to always %-encode the single-byte character codes of those US-ASCII character repertoire that have to be %-encoded in a URI segment, whether or not the segment is the first or later one in a no-scheme relative reference.  (Note: In this case, SP is always %-encoded as %20 and there is no difficulty supporting whitespace-separated lists of IRIs.) 

  9. To ensure interoperability, no non-ASCII codes should be %-encoded in IRIs.  The resulting URIs will not contain any %-encoded bytes that are part of anything but UTF8 code sequences.  In this case, the IRI is always recoverable by restoring those Unicode characters whose UTF8 encoding requires more than one %-encoded byte.  [Note: the Unicode characters having single-byte UTF-8 encodings are meant to be %-escaped in satisfaction of (8) and are not decoded lest they alter the URI syntax. 

> NEEDS-DISCUSSION: ODF 1.2 Part 1 "IRI" abuse
> --------------------------------------------
>                 Key: OFFICE-3342
>                 URL: http://tools.oasis-open.org/issues/browse/OFFICE-3342
>             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
>          Issue Type: Bug
>          Components: General, OpenFormula, Part 1 (Schema), Part 2 (Formulas), Schema and Datatypes
>            Reporter: Dennis Hamilton
>            Assignee: Dennis Hamilton
>             Fix For: ODF 1.2 CD 06
> There are over 20 places in ODF 1.2 CD05 Part 1 where the term "IRI" is used without reference or explanation.  These are often in the same statement where URI/URL are used and it is not clear whether these are being assumed to be interchangeable or different.  
> These mentions of IRI are too casual.  We should perhaps establish that we assume all provisions for URI references in Part 1 are subject to IRI encoding and choose to use IRI consistently.  We might need to be careful that we don't overstep existing provision on URIs used as part of attributes defined by other specifications, such as xhtml:href and xlink:href, however.  We may also need to say more about  URI references when they use XML Schema Datatype anyURI.
> Whatever we do, it is a defect to continue to use IRI casually and with neither definition nor reference to an authoritative source.
> This is related to the similar situation in ODF 1.2 CD05 Part 3, addressed by issue OFFICE-2685 and any resolution in part 1 should be consistent.
> There may also be need for IRI clarification, and clarification around the permissable use of relative URIs in OpenFormula when an OpenFormula expression employs a URI in one of its forms for a reference.

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]