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: 17.5 proposal


I have been through the tangle of posts on this issue, again, and I 
think this represents an acceptable proposal:

A relative-path reference *(as defined in ァ4.2 of [RFC3986], except
that it may contain the additional characters that are allowed in IRI
references [RFC3987])* that occurs in a file that is contained in a
package has to be resolved exactly as it would be resolved if the whole
package gets unzipped into a directory at its current location. The base
IRI for resolving relative-path references is the one that has to be
used to retrieve the (unzipped) file that contains the relative-path

(see Michael' original post: 

the second paragraph (assume that Dennis and I can obtain the correct 
numbers for the first paragraph):

ODF 1.0 IS 26300
Section page line page line

17.5 686 18 699 17

In ODF 1.0 [IS 26300] replace the entire paragraph

All other kinds of URI[IRI] references, namely the ones that start with a
protocol (like http:), an authority (i.e., //) or an absolute-path 
(i.e., /)
do not need any special processing. This especially means that
absolute-paths do not reference files inside the package, but within the
hierarchy the package is contained in, for instance the file system.
URI[IRI] references inside a package may leave the package, but once they
have left the package, they never can return into the package or another

with the paragraph

Non-relative-path references shall not refer to files inside a package.
Relative-path references having paths that traverse out of the package must
not reference files inside any package.

Noting that we will also have to update the RFC references:

[RFC398*6*]	*T. Berners-Lee,* R. Fielding, L. Masinter, Uniform Resource
Identifier (URI):
Generic Syntax, http://www.ietf.org/rfc/rfc3986.txt, IETF, 2005.

BTW, I did not get to talk to Makoto about the first paragraph, I had 
only asked about Dennis's most recent proposal. He had not reviewed the 
IRI traffic when we were together in Jeju.

Apologies for the late posting.

Hope everyone is having a great day!


PS: The discussion on this issue has made me realize more than any other 
how badly email performs for this type of work. No suggestions of a 
better alternative, just an observation.

Patrick Durusau 
Chair, V1 - US TAG to JTC 1/SC 34 
Convener, JTC 1/SC 34/WG 3 (Topic Maps) 
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300 
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps) 

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