Comments on Latest OPC draft -- Clause 8 Package Model

[caroline arms]

The last batch of comments I have ready before the call are for Clause 8.

I can work on the remaining clauses before the next call.  Sorry to miss
this one.

      Caroline


8.1
Last paragraph:  One of the few places I find "pack URI scheme"    The
sentence doesn't match the definition in Terms and Definitions, in that it
uses "URIs", not "IRIs".

8.2.4
I would use "in place" rather than "in-place"

8.2.5
Item 3 is hardly syntactic and therefore doesn't really contribute to
conformance -- as implied by the intro to the list of requirements.
However, the need to follow its guidance is stressed and cited in 8.5.4.1
and 9.2.3.2.1
We can probably live with this.

Item 5 ends with two periods.

8.3.2 is now title Pack Scheme  (no URI or IRI)
Only "IRI" is used in the text.

8.4.1
First paragraph
I would include the title for clause 6.5 of RFC 3987 -- Use of IRIs  Should
the first mention of RFC 3987 actually be RFC 3986?

Second paragraph.
Another place where "preprocessing" is used as a noun.  I would substitute
"pre-processing outline"  or similar.  See earlier message with comments on
Annex A.

8.4.3.3, 8.4.3.4, 8.4.3.5,
Each of these subclauses uses the same awkward structure of a similar
sentence.
  that ("bar.xml")    stops the reader in the middle of the complete phrase
that defines what ("bar.xml") represents.

I would move the parenthesized ("bar.xml") later in the sentence, changing
  Likewise, the path component ("/") of the base IRI and that ("bar.xml")
of the relative reference are merged. The
merge routine emits "/bar.xml".
TO
  Likewise, the path component ("/") of the base IRI and that of the
relative reference ("bar.xml") are merged. The
merge routine emits "/bar.xml".

The first parenthesized component is not grammatically awkward, but could
be moved for symmetry.
YIELDING
Likewise, the path component of the base IRI ("/") and that of the relative
reference ("bar.xml") are merged. The
merge routine emits "/bar.xml".

NOTE:  There are several instances of the same awkward structure in these
subclauses.  I won't repeat the explanation.

8.4.3.4
second paragraph
Begins "As in the previous case" but the word "case" has a different
meaning in these clauses.
Perhaps replace with "example"

8.4.3.5 has a title that is very close to the title for 8.4.3.4.
I wonder whether that can be addressed.  I'm a little afraid that someone
might eliminate the second dot/period by mistake when editing.  I wondered
about "Double-dot" but the RFC doesn't use that term.

8.5.1.
Third paragraph.  I'm afraid I don't understand Murata-san's response to my
comment or what his intent is wrt the specification text.  I still find the
sentence unclear.

8.5.3.1
I think we need to know why the requirement that is reflected in Annex H of
the 2012 spec as M.1.25 was dropped.  Was it an inadvertent deletion?

8.5.4.3
There is a reference at the bottom of the TargetMode row to this clause.
It should probably go to §C.4.
Aside:  I think it may be unwise to try and drop the schemas from Part 2
this time around.  It may delay things unnecessarily.

8.5.5.1
Title needs Relationships in the plural

Second paragraph
I would replace "an XML document" with "the XML document"

8.5.5.2
Second paragraph
I would replace "an XML document" with "the XML document"

8.5.5.3
Title needs Parts in the plural.  See diagram and the text that follows it.

I would make the title
  Relationships Parts related to Digital Signature Markup
and provide a reference to Clause 12.

The diagram would be better if it explained that the arrows represented
relationships.

8.5.5.4
First paragraph:
Delete "of" from "outside of"

8.5.5.5
First paragraph:
I would change "each using unique Id values" to
  "each using a unique Id value"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20180404/d9b0fb9a/attachment-0001.html>