My personal draft based on WD 3.1 (OPC)

[caroline arms]

Murata-san,

So far, I have got through Clause 8.  I have to break now, but will
try to get back to Clause 9 later today.  Note that although I have
focused on your changes, some comments may relate to earlier text.

As a general comment, more for Rex, I notice that references to the
other parts of ISO-IEC 29500 use a variety of forms.  The next time
you, Rex, take a pass over the document, you might normalize them.

    Hoping this helps.   Caroline

On Tue, Aug 23, 2016 at 5:16 AM, MURATA Makoto <eb2m-mrt at asahi-net.or.jp> wrote:
> Dear collegues,
>
> I created my personal draft based on WD 3.1.
>
> It is available at:
> https://www.assembla.com/spaces/IS29500/documents/dNZ1eWArer5OkDacwqEsg8/download/dNZ1eWArer5OkDacwqEsg8
>
> Here is a list of changes.
>
> Throughout
>
> "relationships part" -> "Relationships part"
> "non-relationships part" -> "part that is not a Relationships part"
>
> 3. Terminology
>
> I deleted "part relationship" from Clause 3, since
> we already have "relationship, part" in this clause.
>
> 5.2 Diagram notes
>
> Since we decided not to rely on diagrams in Prague,
> I deleted this subclause.
>
> 8.5.2 Relationships Part
>
> Rewrote based on my email "Rewrite for not using "source
> of a Relationships part".  In WD 3.1, we used the term
> "the source of a relationship" and "the source of a
> Relationship part".  This rewrite removes the second.
>
> 8.5.3.2 Relationships Elemeent
>
> Added a note about the schema.
>
> 8.5.3.3 Relationship Elemeent
>
> Added a note about the schema.
>
> 9.2.3.2.2 Types
>
> I deleted diagrams, rewrote attribute tables using the
> Part 1/4 style, and added some prose instead of the
> diagrams.
>
> 9.2.3.2.3 Default
>
> Ditto.
>
> 9.2.3.2.4 Override
>
> Ditto.
>
> Annex I
>
> In Prague, as part of the DR 13-0002 discussions,
> we agreed to introduce another annex.
>
> Re Murata-san’s mail of 2016-06-08, “Let me try again: DR
> 13-0002”, re “Guidelines for Format Designers” (see
> https://goo.gl/gzIX9y) we agreed to spin off this proposal
> from this DR’s resolution, and to make it a new (informative)
> annex. Murata-san will revise it to change the
> “allow/disallow” phrases to “should specify whether they
> allow or disallow”. Later, he’ll add text for digital
> signatures.
>
> I introduced a slightly revised version of the proposed annex.
>
> --
> Regards,
>
> Makoto
-------------- next part --------------
3 Normative references

3rd added digital signatures reference runs into ISO 8601 reference.

4 Terms and Definitions

Pack URI definition runs into following definition

Document now uses "Pack IRI" in 8.3.2 and 8.3.3  Should the definition be changed?

4.36 Relationships part.  Looks odd with capital letter.  We don't include any other part types in this list.  Do we really need this?  

8 Package model

8.3.2 refers to a Note but the note hasn't been added from N345.  If the note is not going to be added, the reference to it should be removed.

8.3.6
Case 3: Within a Relationships part /_rels/.rels of the entire package
Better might be
   Case 3: Within the Relationships part /_rels/.rels associated with the package as a whole
 
Case 2: Within a Relationships part for some part
Better might be
   Case 2: Within a Relationships part for a part within the package

and Case 3 might come before Case 2.

8.4
"a preprocessing" is very awkward usage — would not be used by a native English speaker.  I suggest changing it here and in Annex A.  Could be "a preprocessing approach" in this context.

8.5.2
I would change
>>>
A Relationships Part is a container of those relationships which have the same source. 	
Names of Relationships parts shall match one of the two cases.  Names of the other parts shall not match either case.
>>>
  to
>>>
A Relationships Part is a container for relationships which share the same source. 	
Names of Relationships parts shall match one of two cases, listed below.  Names of other parts shall not match either case.
>>>

In Case 2, it is not clear what "in it" refers to.  I suggest rewording in both cases as "in this Relationships part".

When I got further down, I found the expression of the naming convention relating a part and its associated Relationships part awkward and suspect the relationship could be made clearer with a more complete re-write.

>>>
A Relationships Part is a container for relationships which share the same source.

A Relationships part shall be associated with the package as a whole or with a part within the package that is not a Relationships part. Names for Relationships parts for the two cases are shown below.  Names that match these cases shall not be used for parts that are not Relationships parts.

Case 1:  A Relationships part associated with the package as a whole has the name “/_rels/.rels”

Every relationship contained in this Relationships part shall have the package as the source.

Case 2: A Relationships part associated with a part within the package has a name derived from the name of the associated part in the following way.

The name of the part that is the source of all relationships in the Relationships part is used to derive the name for the Relationships part by inserting “_rels” as an I18N segment immediately before the last segment and adding “.rels” at the end of the  last segment.
>>>

8.5.3

I would adapt
>>>
The content of a Relationships part shall be an XML document.  After the removal of any extensions by an MCE processor as specified in ISO/IEC 29500-3, a Relationships part shall be a schema-valid XML document against opc-relationships.xsd, as described in Annex C.
>>>

to 
>>>
A Relationships part shall be an XML document.  After the removal of any extensions by an MCE processor as specified in ISO/IEC 29500-3, a Relationships part shall be a schema-valid XML document against opc-relationships.xsd located in Annex C, §C.5.
>>>

Right at the end of 8.5.3 there is a spurious tab character in the middle of "Schema"

******



Annex A.

I would change
>>>
This annex specifies a preprocessing for the conversion of such Unicode strings to relative references.
This preprocessing is neither required nor recommended.
This preprocessing has eight steps.  Some implementations support only some of them.
>>>
to avoid use of "a preprocessing" or "this preprocessing".