<div dir="ltr"><div>Caroline,</div><div><br></div><div>> I am a bit concerned about giving relationship-specific definitions to</div><div>> "source" and "target" -- given that those words may need to be used in</div><div>> different senses in Parts 1 and 4. "Target" is certainly used in</div><div>> connection with hyperlinks in part 1. And "source" is used to discuss</div><div>> data sources in 11.7 -- sources, which in this situation, are targets</div><div>> of relationships.</div><div><br></div><div>As you suggested, we can define "relationship source" and</div><div>"relationship target" and can continue to use "source" and "part" if</div><div>there is no fear of confusion.</div><div><br></div><div>> I understand your wish to deal with the fact that not all relationship</div><div>> sources are parts, but I'm concerned about the ramifications of your</div><div>> proposal to address the issue. I find myself wondering whether</div><div>> defining "relationship source" (to include the package as a whole as</div><div>> well as source parts) as well as "source part" might work. But I</div><div>> can't say until I have a better grasp of your proposals for the text</div><div>> about relationships.</div><div><br></div><div>I introduced "the source of a relationships part". I thought that this</div><div>term would make things simpler, but it appears that it made things</div><div>worse. I am now wondering if we should say "the part with which a</div><div>relationship part is associated with" might be good enough.</div><div><br></div><div>> A couple of other general thoughts/questions:</div><div>> </div><div>> 1. I'm beginning to think that an equivalent to Annex G, the table</div><div>> with guidelines for meeting conformance, would be worth having. I</div><div>> seem to remember that a reason for dropping it was the</div><div>> implementer/producer/consumer perspective. But having the constraints</div><div>> clearly summarized from a document/package perspective could be</div><div>> valuable. I found myself wanting to rely on it as I explored issues</div><div>> wrt relationships, and particularly to understand what Part 1 requires</div><div>> for a package (e.g. for a Word document) but OPC does not. For</div><div>> example, Part 1 describes "unknown parts" and makes it clear that they</div><div>> can be ignored. In Part 2, the only reasonable way to determine</div><div>> whether all parts need to be the target of a relationship is by seeing</div><div>> that there is no such requirement in Annex G.</div><div><br></div><div>Having read your comment, I now think Annex G should sketch what is</div><div>typically required by OPC-based formats (e.g., OOXML). (An OPC-based</div><div>format may define relationship types and enumerate media types for OPC</div><div>parts. It may further impose additional requirements.) By doing so,</div><div>we can clearly distinguish what is required by OPC and what may be</div><div>required by OPC-based formats. 29500-2 should clearly define</div><div>conformance requirements of OPC. 29500-1 should make clear its own</div><div>additional requirements.</div><div><br></div><div>I still do not believe that Annex G should repeat all conformance</div><div>requirements in the body text.</div><div><br></div><div>> 2. There is occasionally a semantic confusion, in 2012 text and in</div><div>> your changes, between the "source" "of" or "for" a relationships part</div><div>> and the source for all the individual relationships in that part. In</div><div>> practice the "source" plays both roles, of course. That fact might be</div><div>> stressed a little more. Alternatively, we good standardize on "source</div><div>> for" a relationships part and the "source of" an individual</div><div>> relationship.</div><div><br></div><div>I now think that we should give up sources for relationships parts.</div><div><br></div><div>> 3. You have deleted all the diagrams in clause 8.5. I am concerned</div><div>> that the diagrams convey some substance that is no longer present in</div><div>> the remaining content, for example, when attributes are required in</div><div>> Relationship elements. And it seems odd that the Relationships </div><div>> Element (clause 9.3.2.1 in published 2012 Part2) now has now text,</div><div>> just two minimal tables. Has the removal of the diagrams been</div><div>> discussed and agreed to? I don't remember it but it could easily</div><div>> have happened at a face-to-face meeting.</div><div><br></div><div>This is my personal rewite, and there are no agreements.</div><div><br></div><div>No other parts of OOXML use diagrams for defining syntactical</div><div>requirements on XML documents. Rather, schemas normatively define</div><div>them. I think that we should do the same thing.</div><div><br></div><div>>4. I think that clause 7 (Overview) would benefit from some general</div><div>> informative statements (and maybe examples) about</div><div>> implementation-dependent possibilities, such as additional</div><div>> constraints (e.g. needing relationship elements to avoid parts being</div><div>> "unknown), new relationship types, etc.</div><div><br></div><div>> Attached is a copy of</div><div>> clause 8-5 extracted from your draft and with changes accepted. It</div><div>> yields more questions, some suggestions of substance and others of a</div><div>> grammatical or style nature.</div><div><br></div><div>Attached is my reply to your comments in you draft. I did not </div><div>edit the body text but merely added my comments.</div><div><br></div><div>I can create a revised version, but I think that we should first</div><div>discuss the current version and the attached document. In Prague, we</div><div>might want to create a revised version.</div><div><br></div><div>Regards,</div><div>Makoto</div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-06-01 2:28 GMT+09:00 caroline arms <span dir="ltr"><<a href="mailto:caroline.arms@gmail.com" target="_blank">caroline.arms@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Murata-san, et al.,<br>
<br>
I have spent some time trying to say something helpful about the issue<br>
of changing the definitions associated with relationships.<br>
Unfortunately, I have found reading your proposed changes to clause<br>
8.5 (Relationships) rather confusing and keep finding new concerns<br>
that send me off in new directions of exploration. I feel a need to<br>
understand your proposals for clause 8.5 before making specific<br>
comments on terms and definitions.<br>
<br>
Today is the last day before my vacation and I do not have time to do<br>
anything more. So what I am sending includes plenty of questions.<br>
<br>
I am a bit concerned about giving relationship-specific definitions to<br>
"source" and "target" -- given that those words may need to be used in<br>
different senses in Parts 1 and 4. "Target" is certainly used in<br>
connection with hyperlinks in part 1. And "source" is used to discuss<br>
data sources in 11.7 -- sources, which in this situation, are targets<br>
of relationships.<br>
<br>
I understand your wish to deal with the fact that not all relationship<br>
sources are parts, but I'm concerned about the ramifications of your<br>
proposal to address the issue. I find myself wondering whether<br>
defining "relationship source" (to include the package as a whole as<br>
well as source parts) as well as "source part" might work. But I<br>
can't say until I have a better grasp of your proposals for the text<br>
about relationships.<br>
<br>
A couple of other general thoughts/questions:<br>
<br>
1. I'm beginning to think that an equivalent to Annex G, the table<br>
with guidelines for meeting conformance, would be worth having. I<br>
seem to remember that a reason for dropping it was the<br>
implementer/producer/consumer perspective. But having the constraints<br>
clearly summarized from a document/package perspective could be<br>
valuable. I found myself wanting to rely on it as I explored issues<br>
wrt relationships, and particularly to understand what Part 1 requires<br>
for a package (e.g. for a Word document) but OPC does not. For<br>
example, Part 1 describes "unknown parts" and makes it clear that they<br>
can be ignored. In Part 2, the only reasonable way to determine<br>
whether all parts need to be the target of a relationship is by seeing<br>
that there is no such requirement in Annex G.<br>
<br>
2. There is occasionally a semantic confusion, in 2012 text and in<br>
your changes, between the "source" "of" or "for" a relationships part<br>
and the source for all the individual relationships in that part. In<br>
practice the "source" plays both roles, of course. That fact might be<br>
stressed a little more. Alternatively, we good standardize on "source<br>
for" a relationships part and the "source of" an individual<br>
relationship.<br>
<br>
3. You have deleted all the diagrams in clause 8.5. I am concerned<br>
that the diagrams convey some substance that is no longer present in<br>
the remaining content, for example, when attributes are required in<br>
Relationship elements. And it seems odd that the Relationships<br>
Element (clause 9.3.2.1 in published 2012 Part2) now has now text,<br>
just two minimal tables. Has the removal of the diagrams been<br>
discussed and agreed to? I don't remember it but it could easily have<br>
happened at a face-to-face meeting.<br>
<br>
4. I think that clause 7 (Overview) would benefit from some general<br>
informative statements (and maybe examples) about<br>
implementation-dependent possibilities, such as additional constraints<br>
(e.g. needing relationship elements to avoid parts being "unknown),<br>
new relationship types, etc.<br>
<br>
Attached is a copy of clause 8-5 extracted from your draft and with<br>
changes accepted. It yields more questions, some suggestions of<br>
substance and others of a grammatical or style nature.<br>
<br>
Enjoy the face-to-face meeting.<br>
<br>
Best from Caroline<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><br>Praying for the victims of the Japan Tohoku earthquake<br><br>Makoto</div>
</div>