OPC part names and referenes

[MURATA Makoto]

John,

2014/1/3 John Haug <johnhaug at exchange.microsoft.com>:
> For my part, it's going to take some time to ramp up mentally on the URI/IRI/LEIRI and relative/absolute/etc. nuances we've discussed previously before I can comment halfway intelligently on this topic.

Let me give a very short overview.

- URIs do not allow non-ASCII.  In other words, URIs are ASCII strings.

- IRIs allow non-ASCII characters.

- LEIRIs allow some more characters, which are arguably problematic
but also arguably useful.

- Conversion from LEIRIs to IRIs and that from IRIs to URIs are done by
  %HH.

- Absolute-path references begin with "/", while relative-path
references don't.
   Both absolute-path references and relative-path references are relative
   references (i.e., no "http://" or some other scheme).

Regards,
Makoto



>
> Since it came to mind, here are other references people should recall.
> 1. E-mail from June 2011 and attachment (Murata-san's comments on Annex A conversion steps) - http://mailman.vse.cz/pipermail/sc34wg4/2011-June/002305.html
> 2. WG 4 N 0207 from Sept 2011 - http://kikaku.itscj.ipsj.or.jp/sc34/wg4/archive/sc34-wg4-2011-0207.html
> 3. E-mail thread from May 2013 "DRs related to Part names" - last mail in the thread at http://mailman.vse.cz/pipermail/sc34wg4/2013-May/002908.html
>
> John
>
> -----Original Message-----
> From: eb2mmrt at gmail.com [mailto:eb2mmrt at gmail.com] On Behalf Of MURATA Makoto
> Sent: Saturday, December 28, 2013 6:25 AM
> To: SC34
> Subject: OPC part names and referenes
>
> The more I think about OPC, the more confused I am.
>
> I have thought that references to OPC parts ("Unicode string"
> in Annex A of OPC) can contain non-ASCII characaters and that such non-ASCII characters are percent-encoded before referenced OPC parts are located.  I have also thought that references to OPC parts are resolved relative to containing OPC parts when they do not begin with "/".
>
> However, my experiment with .Net in F# appears to show I am mistaken.  It reports errors if references to OPC parts contain non-ASCII characters.  Ir also reports errors if references to OPC parts do not begin with "/".
>
> I plan to manually edit OOXML documents and XPS documents and handle them by MS-Office and XPS viewers.
>
> Here is my F# program.
>
> open System.IO.Packaging
> open System
>
> let readOPC() =
>     let package = Package.Open("f:test.opc", IO.FileMode.Open)
>     let uri = new Uri(Uri.EscapeUriString "/fあ/f1", UriKind.Relative)
>     let part =  package.GetPart(uri)
>     let enum = part.GetRelationships().GetEnumerator()
>     while (enum.MoveNext()) do
>         let relship = enum.Current
>         let targetURI = relship.TargetUri
>         try
>             let targetPart = package.GetPart(targetURI)
>             let s = targetPart.GetStream()
>             System.Console.WriteLine("Success: {0} {1}", targetURI,
> s.ReadByte())
>         with
>             | :? System.ArgumentException ->
> System.Console.WriteLine("Error: {0}", targetURI)
>     package.Close()
>
> readOPC()
>
>
> Regards,
> Makoto
>
> -----Original Message-----
> From: eb2mmrt at gmail.com [mailto:eb2mmrt at gmail.com] On Behalf Of MURATA Makoto
> Sent: Tuesday, December 24, 2013 4:16 AM
> To: SC34
> Subject: OPC part names and referenes
>
> Dear colleagues,
>
> Merry Christmas!
>
> I am trying to implement Section 2 of the Japanese proposal
> (http://kikaku.itscj.ipsj.or.jp/sc34/wg4/archive/sc34-wg4-2011-0207.html)
> for improving part names and referenes.
>
> While doing so, I studied the conversion from part references (which are relative) to part names again.  Here are some random thoughts.
>
> 1) Leading "/"
>
> In Seattle, we learned from OPC experts that references beginning with "/" and those not beginning with it are resolved differently.
>
>
> Proposal: Explicitly state differences between these two types of references.  A reference to RFC 3986 is not good enough.
>
> 2) Resolution of relative URI referennces
>
> Neither OPC part references (or Unicode strings as specified in Annex A) nor OPC part names contain schemes (e.g., http:).  Should we nevertheless rely on resolution of relative URI references for the conversion from OPC part references to OPC part names?  In other words, should we first create aboslute URIs thus introducing schemes and then construct OPC part names by removing schemes?
>
> Proposal: Stop relying on resolution of relative URI references.
> Rather, introduce "base OPC part name", which is the OPC part name of the containing OPC part, and introduce a procedure for merging base OPC part names and OPC part references.  This processing model does not have to touch schemes.
>
> 3) xml:base
>
> Do we really have to allow xml:base (and other similar mechanisms) to change the interpretation of OPC part references?  If such a mechaism specifies irrelevant URIs such as http://www.example.com, how should we interpret OPC part references?
>
> Proposal: Stop using xml:base (and other similar mechanisms).
>
>
> Regards,
> Makoto



-- 

Praying for the victims of the Japan Tohoku earthquake

Makoto