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