[OASIS Issue Tracker] Issue Comment Edited: (OFFICE-2685)NEEDS-DISCUSSION: ODF 1.2 Part 3 "IRI" and "relative IRI" used throughoutare never defined

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

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

Dennis Hamilton edited comment on OFFICE-2685 at 8/15/10 4:59 PM:
------------------------------------------------------------------

An afterthough.

You might wonder why, in this particular case of URIs, IRI encodings, relative IRI references, manifest:full-path entries and Zip archive names for archived files, there is all this fuss when there is nothing so fussy elsewhere.

The answer is, it is this fussy everywhere.  The URI and URL specifications are very clear that these precise kinds of considertaions arise in the handling of URI resolution when one passes through multi-technology layers in tracing the different segments, even with a known scheme but especially in scheme-neutral (i.e., noscheme) forms.  The RFCs are explicit about where this happens and where something more must be said for the "application" to work.  

When we are working in a relative monoculture of conventions, the cases have been worked out and we need not be any the wiser.  Just the same, there are often dramatic differences in what an API or a browser or a web serve accepts and how it is treated in the actual underlying technology.  One particularly clear-cut case is when one system is case sensitive and another is not.  The case sensitive system will fail on some URLs that the case-insensitive system will not, when resolving URLs.  On the other hand, when creating resources, the case-insensitive system may object to an apparent duplicate when the case-sensitive system will not.  So implementations of Zip utilities may complain when it appears that two package files have the same location for extraction through a case-insensitive segment or has no location for extraction through a case-sensitive segment.

The usual practice has been to use monocase segment texts for Zip packages that must cross platforms and technologies.  There are also polite limitations of the character repertoire used and in limiting the length of segments.  There are also common practices in the form of the end-segment that is though of as identifying (with the qualification of all the preceding URI segments) the actual resource.  For example, the use of recognized filename extensions is not part of the URL specification but it certainly arises as a naming practice for ODF packages and for package files withih such packages.   Note that the names generated within ODF producers and the standardized names for specific package files are all acceptable under such reduced-use of the potentially extensive possibiilty for IRIs.

In creating a new case for technologies that URI references are resolved through, the task of dealing with all of these matters falls to us on the ODF TC.  Accepting that it makes sense to use IRIs for no-scheme in-package relative URI references in ODF, we must then deal with all the places where IRI edge cases and boundaries arise and have to be specified in an interoperably-implementable way. 

If we accept that there is an use case (or simply a political necessity) to provide for IRIs in the identification of package files via URIs in XML markup, this becomes our task.

      was (Author: orcmid):
    An afterthough.

You might wonder why, in this particular case of URIs, IRI encodings, relative IRI references, manifest:full-path entries and Zip archive names for archived files, there is all this fuss when there is nothing so fussy elsewhere.

The answer is, it is this fussy everywhere.  The URI and URL specifications are very clear that these precise kinds of considertaions arise in the handling of URI resolution when one passes through multi-technology layers in tracing the different segments, even with a known scheme but especially in scheme-neutral (i.e., noscheme) forms.  The RFCs are explicit about where this happens and where something more must be said for the "application" to work.  

When we are working in a relative monoculture of conventions, the cases have been worked out and we need not be any the wiser.  Just the same, there are often dramatic differences in what an API or a browser or a web serve accepts and how it is treated in the actual underlying technology.  I particularly clear-cut case is when one system is case sensitive and another is not.  The case sensitive system will fail on some URLs that the case-insensitive system will not, when resolving URLs.  On the other hand, when creating resources, the case-insensitive system may object to an apparent duplicate when the case-sensitive system will not.  So implementations of Zip utilities may complain when it appears that two package files have the same location for extraction through a case-insensitive segment or has no location for extraction through a case-sensitive segment.

The usual practice has been to use monocase segment texts for Zip packages that must cross platforms and technologies.  There are also polite limitations of the character repertoire used and in limiting the length of segments.  There are also common practices in the form of the end-segment that is though of as identifying (with the qualification of all the preceding URI segments) the actual resource.  For example, the use of recognized filename extensions is not part of the URL specification but it certainly arises as a naming practice for ODF packages and for package files withih such packages.  (Note that the names generated within ODF producers and the standardized names for specific package files are all acceptable under such reduced-use of the potentially extensive possibiilty for IRIs.

In creating a new case for technologies that URI references are resolved through, the task of dealing with all of these matters falls to us on the ODF TC.  Accepting that it makes sense to use IRIs for no-scheme in-package relative URI references in OD, we must then deal with all the places where IRI edge cases and boundaries arise and have to be specified in an interoperably-implementable way.  If we accept that there is an use case (or simply a political necessity) to provide for IRIs in the identification of package files via URIs in XML markup, this becomes our task.
  
> NEEDS-DISCUSSION: ODF 1.2 Part 3 "IRI" and "relative IRI" used throughout are never defined
> -------------------------------------------------------------------------------------------
>
>                 Key: OFFICE-2685
>                 URL: http://tools.oasis-open.org/issues/browse/OFFICE-2685
>             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
>          Issue Type: Bug
>          Components: Packaging, Part 3 (Packages), Schema and Datatypes
>    Affects Versions: ODF 1.2 CD 05
>         Environment: This applies to all versions of OpenDocument-v1.2-part3-cd1 through -rev04.  It also impacts ODF 1.2 Part 1 and ODF 1.2 Part 2 wherever anyURI or equivalent datatype is used in a relative reference.
>            Reporter: Dennis Hamilton
>            Assignee: Dennis Hamilton
>             Fix For: ODF 1.2 CD 06
>
>
> The terms "IRI" and "relative IRI" are used throughout ODF 1.2 Part 3.  
> 1. There are no definitions offered for these terms.
>  2. There are no references (normative or otherwise) to sources on this terminology (although [RFC3987] would appear to be a good choice).
>  3. The manner in which IRIs are to be mapped to URIs in those places where resolution involves URI segments within a package is not defined, nor is the relationship to IRI-encoding in URIs accounted for in the definition of (a) the manifest:full-path attribute or (b) the format for names of files in the ZIP data units that carry files within the ZIP archive.  In particular, there should be attention to [RFC3987] sections 6.2-6.4, not merely 6.5.

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