CRA Notes -- now complete Re: My personal draft based on WD 3.1 (OPC)

[caroline arms]

I have now gone through the subclauses you changed in Clause 9 and
expanded the notes, which are attached.  The attached file includes
the earlier notes sent on 9/25 on the main part of the draft, but not
my notes on the new Annex I, sent a couple of days ago.

I've dated this file 9/26, because it is 9/26 in Seoul.  Here it is
still 9/25, but that seemed to be an easy way to distinguish the two
files.

Have fun.  I hope the notes are helpful.

    Caroline

On Sun, Sep 25, 2016 at 3:14 PM, caroline arms <caroline.arms at gmail.com> wrote:
> 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"

9.2.3.2 Media Types Stream Markup

General comment ��� I believe the diagrams specify that various attributes that might logically be repeated are not repeatable.  For example, logically, multiple extension attributes could be specified in a Default element for mapping to the same media type (e.g. .jpg and .jpeg to image/jpeg).  And logically, multiple part names could be included in an Override element for mapping to the same media type.  Assuming repeating these attributes is not permitted, I think that should be stated explicitly either in the table or the narrative.

9.2.3.2.3 Default
In bottom line in Description in table row for Extension "in" is doubled.

Also, I think the plurals in the opening sentence may be misleading if my assumption that extensions are not repeatable is correct.

Perhaps "A Default element shall specify the default mappings from the extensions of part names to media types." should be
"A Default element shall specify the default mapping from the extension in a part name to a media type."

9.2.3.2.4 Override
Same problem as for Default ��� doubled "in"

In first sentence, I would replace "on" in "shall specify media types on parts" by "for".  [This was the original text, not a change by Murata-san.]

Also, I think the plurals in the opening sentence may be misleading if my assumption that PartNames are not repeatable.

Perhaps "An Override element shall specify media types on parts that are not covered by, or are not consistent with, the default mappings." should be:
"An Override element shall specify the media type for a part that is not covered by, or is not consistent with, a mapping in a Default mapping."

At end of Description box for PartName attribute, I see a spurious 9.2.3.3.  This probably relates to a style problem for the sentence.


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".