OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

office-comment message

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


Subject: Re: [office-comment] Comments on ODF 1.0 Errata 01 Committee Draft 02


Makoto,

On 08/21/08 01:56, MURATA Makoto (FAMILY Given) wrote:
>>>> First, an absolute IRI reference begins with a scheme (rather than protocol), 
>>>> and it does not start with an authority or an absolute-path.  
>>> This point has not been addressed, since the corrected wording still
>>> allows IRI references to start with an absolute-path.  I believe that
>> I'm not sure if I do understand this. 
> 
> The phrase "All other kinds of IRI references, namely the ones that
> start with a schema (like http:), an authority (i.e., //) or an 
> absolute-path (i.e., /) " in the draft errata means either
> 
> 1) IRI references that start with a scheme  (like http:),
> 2) IRI references that start with an authority (i.e., //), or
> 3) IRI references that start with an absolute-path (i.e., /) 

Yes, but it also includes any other IRI reference that is not a relative 
path.

> 
> The BNF in RFC 3987 is:
> 
>    IRI            = scheme ":" ihier-part [ "?" iquery ]
>                          [ "#" ifragment ]
> 
>    ihier-part     = "//" iauthority ipath-abempty
>                   / ipath-absolute
>                   / ipath-rootless
>                   / ipath-empty
> 
>    IRI-reference  = IRI / irelative-ref
> 
>    absolute-IRI   = scheme ":" ihier-part [ "?" iquery ]
> 
>    irelative-ref  = irelative-part [ "?" iquery ] [ "#" ifragment ]
> 
>    irelative-part = "//" iauthority ipath-abempty
>                        / ipath-absolute
>                   / ipath-noscheme
>                   / ipath-empty
> 
> 
> Thus, 1) is allowed as IRIs or IRI references.  2) and 3) are allowed as
> IRI references only.  Section 4.2 of RFC 3986 clearly states that 2) 
> and 3) are relative references, and the preceding paragraph in the ODF 
> spec already covers relative references.  ipath-noscheme and ipath-empty
> are not mentioned.

The preceding paragraph is:

"A relative-path reference (as described in 6.5 of [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 reference. "

It does not include the term "relative reference", but only 
"relative-path reference". Therefore, the paragraph in question includes 
all kind of IRIs that are not "relative path-references". This includes 
absolute references, but also all kind of relative references that are 
not relative path-references.

So, in my opinion the problem is not that paragraph, but the reference 
to 6.5 of RFC3987.

RFC3986 and its predecessors are defining terms like "relative 
path-reference" or "network-path" references, and a "relative 
path-reference" is exactly the kind of URI/IRI that requires a special 
processing. But RFC3986 is about URIs. ODF supports IRIs as described by 
RFC3987. RFC3987 unfortunately does define these terms, and I could also 
not find any counterparts for them.

Maybe we should say:

"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 [...]"

> 
> I think that you are inviting problems by not relying on RFCs 3986 and
> 3987.

Actually, we are relying on RFC 3986 and RFC 3987. The problem is that 
RFC 3987 is not repeating the definitions of RFC 3986.
> 
> Cheers,
> 

Best regards

Michael


-- 
Michael Brauer, Technical Architect Software Engineering
StarOffice/OpenOffice.org
Sun Microsystems GmbH             Nagelsweg 55
D-20097 Hamburg, Germany          michael.brauer@sun.com
http://sun.com/staroffice         +49 40 23646 500
http://blogs.sun.com/GullFOSS

Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
	   D-85551 Kirchheim-Heimstetten
Amtsgericht Muenchen: HRB 161028
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering


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