More OPC answers

[MURATA Makoto]

2014-05-13 0:48 GMT+09:00 MURATA Makoto <eb2m-mrt at asahi-net.or.jp>:

>
>
>
> 2014-05-12 4:47 GMT+09:00 John Haug <johnhaug at exchange.microsoft.com>:
>
>   For Tuesday’s call.  We received more information this past week on the
>> questions I asked.
>>
>>
>>
>> 1. Regarding steps 1-9 in A.3: They said that the examples in A.4 should
>> illustrate why the steps exist.  For example, see the line for the Unicode
>> string “\a.xml” (4th from bottom).  Without those steps (in particular,
>> 4 and 5), the result would be “/%5Ca.xml” rather than “/a.xml” because the
>> URI that is run through those steps is “%5Ca.xml”.
>>
>
> It appears that the biggest reason for the itemized list  is to
> convert "\a.xml" to "/a.xml" automatically.   We have to do
> that conversion.
>
> I think that this conversion should be done as part of
> the semantics of the pack scheme, rather than
> by the resolution of relative references.
>
> But wait!  Are "/a.xml" and "\a.xml" equivalent?
> If so, equivalent as part names or equivalent as
> relative references (in that case, is "/./a.xml"
> also equivalent?).
>


First, equivalence of relative references should not
be tested.  The next para is extracted from RFC 3986.

   In testing for equivalence, applications should not directly compare
   relative references; the references should be converted to their
   respective target URIs before comparison. ...

 Second, it is allowed to test equivalence of URIs after
converting the baskclash character to the slash character.
The next para is also extracted from RFC 3986.


           For this reason,
   determination of equivalence or difference of URIs is based on string
   comparison, perhaps augmented by reference to additional rules
   provided by URI scheme definitions

So, I think that there is nothing wrong in interpreting "\" as "/", after
relative references are resolved against the pack URI.

I thus think that we do not need A.3.   All what I need is "additional rules
provided by the pack scheme, and the conversion of "\" to "/" is one
of them..

Regards,
Makoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20140513/da130781/attachment.html>