Re: Clauses §8.3.5 and §8.2.2.3

[caroline arms]

Thanks for your response.

I have one substantive question, relating to "in its name"  (in red
below).  As I read 9.1.1.4 in the 2012 published version, I would
understand the constraint to mean that another part's name should not BEGIN
with "/a" or "/A".   And I believe that's what the explanation of derivable
says.  So I might change:

If a package contains a part named “/a”, another part in that package must
not have “/a” or “/A” in its name.
   to
If a package contains a part named “/a”, another part in that package must
not have a name that begins with “/a” or “/A”.

But perhaps I'm missing something

However my main concern about §8.2.2.3 is that it is very confusing as to
its order of normative text and examples.  It is not obvious what the
examples are examples of. Also each of the [Example] blocks holds more than
one example, which makes them very hard to read.

I have several possible suggestions that might make the clause more
readable.  I've listed them as options.  One or more could be followed.

Option 1.  Put everything related to "derivable" before everything related
to "weakly derivable."

Hence:

For each part name N and string S, let the result of concatenating N, the
forward slash and S be denoted by N[s]. A part name N1 is said to be
derivable from another part name N2 if, for some string S, N1 is equivalent
to N2[S].

The name of a part shall not be derivable from the name of another part.

[Example: If a package contains a part named “/a”, another part in that
package must not have “/a” or “/A” in its name. If a package contains a
part named “/segment1/segment2/…/segment*n*”, other parts in that package
must not have names such as “/segment1”, “/SEGMENT1”, “/segment1/segment2”,
“/segment1/SEGMENT2”, or “/segment1/segment2/…/segment*n*-1”. If a package
contains a part named “/Å” where Å is 'ANGSTROM SIGN' (U+212B), another
part in that package should not have in its name “/Å” where Å is 'LATIN
CAPITAL LETTER A WITH RING ABOVE' (U+00C5) because U+212B and U+00C5 are
normalized to the same character sequence. end example]

A part name N1 is said to be weakly derivable from another part name N2 if,
for some string S, the result of applying NFC to N1 is equivalent to the
result of applying NFC to N2[S].
The name of a part should not be weakly derivable from the name of another
part.

[Example: Given N[s] equal to “/a/b” where N is “/a” and S is “b”, then
“/a/b” is derivable from “/a”. A part named “/é/a”, where é is 'LATIN SMALL
LETTER E' (U+0065) followed by 'COMBINING ACUTE ACCENT' (U+0301) is weakly
derivable from “/é”, where é is 'LATIN SMALL LETTER E WITH ACUTE' (U+00E9).
 A part named “/É/a”, where é is 'LATIN CAPITAL LETTER E' (U+0045) followed
by 'COMBINING ACUTE ACCENT' (U+0301) is also weakly derivable. end example
<#_msocom_1>]

Option 2.  Break the text in the [Example] blocks into the independent
examples.
 [Example:
If a package contains a part named “/a”, another part in that package must
not have “/a” or “/A” in its name.

If a package contains a part named “/segment1/segment2/…/segment*n*”, other
parts in that package must not have names such as “/segment1”, “/SEGMENT1”,
“/segment1/segment2”, “/segment1/SEGMENT2”, or “/segment1/segment2/…/segment
*n*-1”.

If a package contains a part named “/Å” where Å is 'ANGSTROM SIGN'
(U+212B), another part in that package should not have in its name “/Å”
where Å is 'LATIN CAPITAL LETTER A WITH RING ABOVE' (U+00C5) because U+212B
and U+00C5 are normalized to the same character sequence. end example]

Option 3.  Explain what the examples are about at the beginning of the
block -- which might require dividing the first example block into two,
since the third example is related to NFC and is a "should not"  whereas
the first two are about derivability and case-insensitive matching.

       To be continued, no doubt ...

       Caroline

On Sat, Jan 20, 2018 at 4:34 PM, MURATA Makoto <eb2m-mrt at asahi-net.or.jp>
wrote:

> Caroline,
>
> Thank you for your careful reviewing!
>
> 2018-01-21 5:53 GMT+09:00 caroline arms <caroline.arms at gmail.com>:
>
>> Murata-san, Rex, et al.
>>
>> I have started to go through the draft.  Rather than wait to the
>> teleconference, I thought I would send emails on issues that are not simply
>> fixing typos or grammar as I come across them.
>>
>> Clause §8.3.5 includes
>> "The path components are equivalent part names, as specified in §8.2.2
>> [M7.3]"
>>
>> Should this point instead to §8.2.2.3 Part Name Equivalence and Integrity
>> in a Package?
>>
>
> "equivalent" is defined in 8.2.2.3, but "part names" is defined
> in  8.2.2.1 and 8.2.2.2.
>
>
>>
>> I find §8.2.2.3 rather confusing and as I read it carefully, I realized
>> that "equivalence" as meant in §8.3.5 might need to incorporate more than
>> ASCII case-insensitive matching -- as equivalence is defined in the first
>> paragraph of §8.2.2.3.  In particular, I wondered whether equivalence after
>> application of NFC was also relevant.
>>
>
> No, they are not.  Microsoft never does NFC to part names.
>
>
>> Perhaps someone more expert than me can weigh in here.
>>
>> I realize that §8.2.2.3 mixes "shall" and "should" -- presumably
>> deliberately.  That probably adds complexity here.
>>
>
> Yes, it is confusing.  But I believe that Microsoft and Apple do different
> things here.  Microsoft never normalizes file names.  Apple always
> does.  Part name crashes by Apple (and possibly others) should
> be avoided.  That's why we have a number of "should" in 8.2.2.3.
>
> Regards,
> Makoto
>
>
>>
>> I have some other concerns about §8.2.2.3, but I would need clarification
>> on what "equivalence" needs to be for §8.3.5 before I could make useful
>> suggestions.
>>
>>     Caroline
>>
>> PS:  Given the government shutdown, please be sure to send important
>> emails to my gmail account (or to the WG4 list).  I'm afraid the shutdown
>> may play havoc with my schedule, just as the threat of a shutdown has been
>> leading to inefficiency over the last few weeks.
>>
>> On Tue, Jan 9, 2018 at 3:46 PM, Rex Jaeschke <rex at rexjaeschke.com> wrote:
>>
>>> Attached is WD3.3 of the OPC Spec.
>>>
>>>
>>>
>>> Once I got it back from Murata-san, here’s what I did:
>>>
>>>
>>>
>>>    1. I adopted all edits from WD3.2 and prior that had been resolved,
>>>    so they no longer show as tracked changes.
>>>    2. I kept all the comments that do not appear to have been resolved.
>>>    3. All Murata-san’s edits proposed since WD3.2 are shown as tracked
>>>    changes.
>>>
>>>
>>>
>>> I propose that at the March F2F meeting, we walk through this document
>>> and accept/reject the proposed edits, and resolve the issues raised in
>>> comments.
>>>
>>>
>>>
>>> Our most-recent discussion of a time line for this spec was to have a
>>> complete version at the end of the March 2018 meeting, and after minor
>>> changes from the F2F meeitng, to send it out for a 2-month CD ballot,
>>> closing before the June F2F. I now think this is quite unrealistic. There
>>> is a lot of work to do yet, and the decisions we make in March will need to
>>> be applied to the spec and then reviewed in the following teleconferences.
>>> We migth have a shot at getting a near-final draft for review of the June
>>> meeting.
>>>
>>>
>>>
>>> Murata-san has long pushed to get rid of informative Annex G [formerly
>>> H], “Guidelines for Meeting Conformance”, while I pushed for keeping
>>> it. And while we agreed to keep it, it still needed serious work to make it
>>> complete. Unfortunately, in its current state, many of its links and
>>> bookmarks are now badly broken, and will be non-trivial to reconstruct. So,
>>> reluctantly, I am dropping my objection to removing this Annex. As such, I
>>> have **not** done any work on repairing/updating this annex. If we drop
>>> this annex, we’ll need to decide what to do about all the [M], [O], and [S]
>>> markers spread throughout the normative text.
>>>
>>>
>>>
>>> In DR 13-0002, Murata-san proposed the addition of a new informative
>>> Annex, “Guidelines for Format Designers” (see https://goo.gl/gzIX9y)”.
>>> As I cannot access this link, I have not added this annex. Murata-san, can
>>> you please circulate this proposed text?
>>>
>>>
>>>
>>> As Caroline will likely not attend the March meeting, I’d like to give
>>> her time to review and submit feedback before then. Likewise for Aarti’s
>>> experts (who likely will not attend that meeting).
>>>
>>>
>>>
>>> We’ll have a big job in March resolving all the open issues, so the more
>>> preparation you can do before then, the better. And, of course, we can do
>>> serious work on this on our January 31 teleconference.
>>>
>>>
>>>
>>> Rex
>>>
>>>
>>>
>>
>>
>
>
> --
>
> Praying for the victims of the Japan Tohoku earthquake
>
> Makoto
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20180121/d1e9b874/attachment-0001.html>