OPC part names and referenes

[MURATA Makoto]

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