Reorganizing examples of relative references resolution in A.3 of OPC

MURATA Makoto eb2m-mrt at asahi-net.or.jp
Sat Jun 14 04:06:06 CEST 2014 

Folks,

If we indeed use relative references for addressing parts, we
are obliged to get rid of the itemized list in A.3.  This is
because of the following sentence in 5.2.1 of RFC 3986.
(http://tools.ietf.org/html/rfc3986#section-5.2.1)

   A URI reference must be transformed to its
   target URI before it can be normalized.

When the user specifies an incorrect URI, Web browsers (including
FireFox and Chrome) silently converts it to a correct URI.  For
example, the backslash character is converted to the slash character.
Such conversion is outside the scope of RFC 3986.

But what should OPC do?  I can think of three options.

A: Use relative references and abandon A.3.

B: Use A.3 and invent our own variation of relative
   references.

C: Adopt the backslash-to-slash conversion (and nothing else)
   and only slightly extend relative references.

I like A and can live with C.

Regards,
Makoto


2014-06-14 10:32 GMT+09:00 MURATA Makoto <eb2m-mrt at asahi-net.or.jp>:

> The space character is treated very similarly to "[".  That
> is, CreatePartUri escapes the space character.  But
> Create reports an error when verbatim space appears,
> and converts escaped space back to verbatim space.
>
> Regards,
> Makoto
>
>
> 2014-06-14 10:27 GMT+09:00 MURATA Makoto <eb2m-mrt at asahi-net.or.jp>:
>
> Dear colleagues,
>>
>> I am still wondering if the itemized list in A.3 of OPC
>> is needed.  How is the itemized list implemented in
>> src\Base\System\IO\Packaging\PackUriHelper.cs ?
>>
>> First, given a string x,
>>
>>   PackUriHelper.CreatePartUri(new Uri(x, UriKind.Relative))
>>
>> performs Steps 1, 2, 3, 4, 5, 6 and 9 but does not support
>>  Steps 7 or 8.  In particular, percent encoded backslashes
>> are converted to verbatim slashes by Steps 4 and 5.
>> Multiple consecutive forward slashes (the target of Step
>> 7) does not cause an error, but a trailing forward slash
>> (the target of Step 8) causes an argument error.
>>
>> Second,
>>
>>   PackUriHelper.Create(baseUri,new Uri(x, UriKind.Relative))
>>
>> reports an error when x contains what is touched by Steps
>> 1, 2, 3, 4, 5, 6, 8, and 9, where baseUri is a valid URI
>> of the http scheme.  Meanwhile,
>>
>>   PackUriHelper.Create(baseUri,part)
>>
>> exhibits interesting results, where part is the output of
>> the CreatePartUri method (the first code snipet).  Step 1
>> done by CreatePartUri is *undone* by the Create method.
>> That is, %5B and %5D are converted back to "[" and "]".
>>
>> Here are my opinions.
>>
>> - Is the behaviour of "[" and "]" (escaping by
>>   CreatePartUri and unescaping by Create) intentional?
>>
>> - One could argue that the support of Steps 1, 2, 3, 4, 5,
>>   6 and 9 in CreatePartUri is merely for recovering from
>>   errors and that these steps are NOT for handling correct
>>   part names.  This is because PackUriHelper.Create
>>   cannot handle part names containing "errors" such as
>>   backslashes.
>>
>> Regards,
>> Makoto
>>
>>
>> 2014-06-09 11:52 GMT+09:00 MURATA Makoto <eb2m-mrt at asahi-net.or.jp>:
>>
>> I made two mistakes.
>>>
>>> First, web requests based the pack scheme are supported.
>>> But this support is done by
>>>
>>>   System.IO.Packaging.PackWebRequest
>>>
>>> rather than
>>>
>>>   System.Net.WebRequest
>>>
>>> Second, PackUriHelper can generate URIs of the pack
>>> scheme.  For example,
>>>
>>>   let baseUri = new Uri("http://www.example.com", UriKind.Absolute)
>>>   let part = new Uri ("/foo", UriKind.Relative)
>>>   let packUri = PackUriHelper.Create(baseUri, part)
>>>
>>>   System.Console.WriteLine("generated uri: {0}", packUri);;
>>>
>>> returns
>>>
>>>   generated uri: pack://http:,,www.example.com,/foo
>>>
>>> Regards,
>>> Makoto
>>>
>>>
>>>
>>> Second,
>>>
>>>
>>> 2014-06-08 15:35 GMT+09:00 MURATA Makoto <eb2m-mrt at asahi-net.or.jp>:
>>>
>>> Folks,
>>>>
>>>> I did some more experiments.  My conclusion is
>>>> that .Net (with the possible exception of Web
>>>> Presentation Foundation) does not support the
>>>> pack scheme.
>>>>
>>>> I thought that System.Uri of .Net can handle
>>>> the pack scheme.  But my experiment suggest
>>>> otherwise.  For example,
>>>>
>>>>  new Uri(@"pack://http%3a,,www.site.com,windows,p1.xps/",
>>>> UriKind.Absolute)
>>>>
>>>> raises a UriFormatException.  I tried all examples shown
>>>> in 29500-2, but none of them parsed correctly.
>>>>
>>>> I also tried
>>>>
>>>>   WebRequest.Create (@"pack://http%3a,,www.site.com,windows,p1.xps/");;
>>>>
>>>> But I got an UriFormatException, again.
>>>>
>>>> PackUriHelper supports the creation of part names,
>>>> which begin with "/".  But they do not appear to support
>>>> the creation of park URIs.
>>>>
>>>> Regards,
>>>> Makoto
>>>>
>>>>
>>>>
>>>> 2014-06-07 15:27 GMT+09:00 MURATA Makoto <eb2m-mrt at asahi-net.or.jp>:
>>>>
>>>> Folks
>>>>>
>>>>> I did an experiment using F# of Visual Studio 2010 and
>>>>> .Net framework 4.
>>>>>
>>>>> For each bullet in the itemized list in A.3., I created an
>>>>> example string.  Then, I executed
>>>>>
>>>>>   PackUriHelper.CreatePartUri(new Uri(x, UriKind.Relative))
>>>>>
>>>>> for each example string.  The source program and the
>>>>> output is available at:
>>>>>
>>>>> https://www.assembla.com/spaces/IS29500/wiki/OPC_Annex_A3_Testing
>>>>>
>>>>>
>>>>> It is not easy to interpret the result of this experiment.
>>>>> One could argue that each input string is a part name.
>>>>> One could also argue that each input string is merely
>>>>> an erroneous input and that the resulting string is a
>>>>> part name.  One could also argue that each string is
>>>>> a Unicode string that can be converted to a part name.
>>>>> We can discuss in Prague.
>>>>>
>>>>> Regards,
>>>>> Makoto
>>>>>
>>>>>
>>>>> 2014-06-05 15:27 GMT+09:00 MURATA Makoto <eb2m-mrt at asahi-net.or.jp>:
>>>>>
>>>>>
>>>>>> Folks,
>>>>>>
>>>>>> I am not thiking about how examples (A.3) of resolution
>>>>>> of relative references in Annex A should be improved.
>>>>>>
>>>>>> A.3 has caused a lot of confusions, since it does not distinguish two
>>>>>> cases: relatvies references beginning with "/" and those not beginning
>>>>>> with it.  The right approach is to clearly use resolution of relative
>>>>>> references as specified in RFC 3986 and demonstrate examples.  In
>>>>>> particular, we should show what the remove_dot_segments and merge
>>>>>> procedures in RFC 3986 do as part of this resolution.
>>>>>>
>>>>>> A related problem is the absense of base URIs in A.3.  Obviously,
>>>>>> base URIs play key reoles in the resolution of relative
>>>>>> references.  Why are they not mentioned?  As a result, all examples
>>>>>> in A.3 appear to begin with "/".  There are no examplses that
>>>>>> do not begin with "/".
>>>>>>
>>>>>> I am trying to reogranize examples thoroughly now.  I will
>>>>>> report back in a few days.
>>>>>>
>>>>>> Regards,
>>>>>> Makoto
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Praying for the victims of the Japan Tohoku earthquake
>>>>>
>>>>> Makoto
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Praying for the victims of the Japan Tohoku earthquake
>>>>
>>>> Makoto
>>>>
>>>
>>>
>>>
>>> --
>>>
>>> Praying for the victims of the Japan Tohoku earthquake
>>>
>>> Makoto
>>>
>>
>>
>>
>> --
>>
>> Praying for the victims of the Japan Tohoku earthquake
>>
>> Makoto
>>
>
>
>
> --
>
> Praying for the victims of the Japan Tohoku earthquake
>
> Makoto
>



-- 

Praying for the victims of the Japan Tohoku earthquake

Makoto
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20140614/46ef8785/attachment.html>

More information about the sc34wg4 mailing list