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