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