[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [office] 17.5 on IRIs
Interesting. I see jurisdictional problems with statements along these lines: Absolute-paths can not reference files inside a package. IRI references inside a package may address anything addressable by an IRI that is outside of a package, but no IRI outside of a package may address any location within any package. I don't think we have jurisdiction over IRIs and over the Zip format. We can restrict how those are applied for ODF (as with the Zip MIME-type hack for ODF packages), but only in the context of their occurrence in the ODF representation of documents. In particular, I don't see how we can say anything about ways applications handle IRIs not found within an ODF-format file and whether schemes that provided access to sub-files inside of an ODF package from outside of that package can be defined or not. It seems to me that we have no jurisdiction over such prospects. I can understand removing the obligation of ODF processors from dealing with IRI schemes in an ODF-format file that would direct them to sub-files in packages other than any holding the ODF-format file in which the IRI appears. Of course, for an IRI whose entire resolution can be delegated to the host operating system, I am not sure why this is much of a concern. MORE THINKING ABOUT RELATIVE PATHS (not the same as RELATIVE URI/IRI) Relative paths must be resolved by the ODF processor, and it is useful to limit the problem and confine resolution to internal sub-files of the same package. If the relative path reaches above the package, as allowed in 17.5, it can then be transformed into a relative path to be resolved using the operating system and with a base location using the directory in which the current package is located. This seems to be what 17.5 is out to accomplish. It is hard to know whether such resolution could retrieve a part of some package and how the processor would be able to detect and prevent that. We can certainly say that relative paths should not lead to such a situation. There is an additional wrinkle in the use of relative paths. Although it is clear that an IRI can be encoded in UTF8 (or UTF16) in the XML attribute that has an IRI as its value, it is not clear whether anything but single-byte codes (and preferably 7-bit only codes to avoid any ambiguity with double-byte coding schemes and single-byte codepage variants) can appear in the part that codes a Zip filename. The cited reference on the Zip format doesn't say boo about the character encoding of filenames for the Zip elements. When the relative IRI refers up and out of the package, handling any Unicodeness will be a matter to be worked out with the hosting platform. (The string of "../" parts that move up to the directory location of the package and are stripped out to leave the directory-relative part are the same in ISO-646 and UTF8 and in wide characters, so no problem there and these disappear in the creation of a package-internal Zip filename.) Finally, I note that 17.5 does not prohibit a relative IRI from being used to refer to the (Zipped) package itself, or another Zipped package. We just don't want to allow IRIs that somehow refer into a package. Just thinking around the ramifications, not proposing at this point ... - Dennis -----Original Message----- From: Jomar Silva [mailto:jomar.silva@br.odfalliance.org] Sent: Monday, September 22, 2008 13:43 To: Patrick Durusau Cc: ODF office Subject: Re: [office] 17.5 on IRIs Hi, I prefer the version 2 of Patrick's proposed text. When I was translating ISO/IEC26.300 to Brazilian Portuguese, I've spent almost a week to find the best way to translate this particular sentence to Portuguese. I think that this proposal number 2 will be easily translated and explicit everything that we need to say. Best, Jomar Patrick Durusau escreveu: [ ... ] > **** > Every IRI reference that is not a relative-path reference does not > need any special processing. Absolute-paths can not reference files > inside a package. IRI references inside a package may address anything > addressable by an IRI that is outside of a package, but no IRI outside > of a package may address any location within any package > **** [ ... ]
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]