Part 2 rewrite for part names and part references

[John Haug]

On yesterday's call, I was asked to write up some notes on part references, given the discussion we wrapped up with around section 9.2 Part Addressing.

My take on the published clause 9.2 and its sole subclause 9.2.1 is that it exists simply to note how (1) relative references and (2) base URIs are handled.  That is: (1) by starting from the part containing the reference rather than, for example, the .rels file, (2a) what the default base URI is for a part and (2b) that a base URI may be explicitly specified if the content type of the part containing the reference supports that.  I think the text under 9.2 is just some trivial introductory verbiage to avoid having an empty clause; 9.2.1 is the real information.

On to 9.3.  Relationships exist as an explicit OPC concept and part/markup because the way in which a reference is stored in the core content parts of an OPC package are specific to those parts' content types.  Relationships are an OPC-common way to represent those references.  They also allow references to have associated metadata information.

9.3.2 Relationship Markup.  Murata-san pointed out the last sentence of this subclause, which disallows use of xml:base.  Given that entire paragraph, I believe the scope of that is disallowing use of xml:base inside the Relationship element markup to specify a base URI for a relative reference.  That is, a value of a Target attribute of a Relationship element that is a relative reference shall always be relative to the part containing the reference - described here as the "Relationships source part" (that language can be improved), aka the part associated with the Relationships part that contains the Relationship element in question.

9.3.2.2 Relationship Element.  This specifies the markup requirements, including that the value of the Target attribute must be a URI reference - either a URI or a relative reference, depending on the value of the TargetMode attribute.  See RFC 3986<http://tools.ietf.org/html/rfc3986>: §4.1 - ABNF defining URI reference as a URI or a relative reference; §3 - ABNF defining URI;  §4.2 - ABNF defining relative reference.

Given the assertion that 9.2.1 exists to discuss concepts, that Relationships are the only way references are stored at the OPC level, that 9.3.2.2 specifies allowable values for the Target attribute in terms of RFC terminology, and that 9.3.2.2 notes that the value of Target is not restricted to the syntax requirements for part names, I don't think we should apply part name ABNF or prose restrictions to the clause about part addressing (9.2 / 9.2.1), as was proposed.  Merging Annex A into this area seems to be a good idea, though.

(Note that all the section numbers in Murata-san's proposed draft document are off by one, since clause 6 Acronyms and Abbreviations seems to be missing from the base document his changes were made to.)

John

From: eb2mmrt at gmail.com [mailto:eb2mmrt at gmail.com] On Behalf Of MURATA Makoto
Sent: Tuesday, February 4, 2014 5:43 AM
To: SC34
Subject: Part 2 rewrite for part names and part references

As the owner of the below DRs, I tried to provide a solution.   See
the attached document.  It implements changes sketched in
WG 4 N 0207.

09-0280 - general DR about sections of OPC assuming non-ASCII is disallowed
09-0281 - terminology; all uses of "part" should specify what kind of part is meant
09-0283 - similar to 09-0280
09-0284 - terminology; need to re-associate the ABNF term names with the prose for part names
09-0285 - terminology; use of "part IRI" and "part URI"
09-0286 - need to update 9.2 (Part Addressing) to specify the format of a reference, based on the changes to be made to 9.1.1 (Part Names)
09-0288 - same as 09-0286, but for 9.3.2 (Relationship Markup)
09-0291 - terminology; specify what "Unicode string" means, based on the changes to be made to 9.1.1
09-0292 - which characters are allowed in a part name (e.g., whitespace, delimiters, special characters)
13-0002 - fix previous changes made to Annex H for introduction of non-ASCII support
10-0015 - clarify "source part" for relationships


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