DR 09-0322 - OPC: Types
Shawn Villaron
shawnv at microsoft.com
Thu Apr 1 14:13:01 CEST 2010
Those changes look good. Unless someone objects, we'll get the mark-up put together and circulate it around so that we can move this to LAST CALL.
Thanks,
shawn
From: Alex Brown [mailto:alexb at griffinbrown.co.uk]
Sent: Thursday, April 01, 2010 3:53 AM
To: Shawn Villaron; SC 34 WG4
Cc: Richard Bretschneider
Subject: RE: DR 09-0322 - OPC: Types
Dear Shawn, all,
If we provide a formal definition for term "relationship type" (which I think we should), then the table on Page 22 should be updated simply to mentioned the term. In other words, we can say that the value of the @Type attribute shall be "a relationship type".
However, what I think what was/is puzzling me here is this mention of a "function" or "role". What do these mean here? Can the same _type_ of relationship play different _roles_ in a package? (I don't think so - the same resource can be the target of different-type relationships, however).
To cut to the chase (and after a chat with Murata-san), I think the relationship type is just an arbitrary URI which the Standard specifies shall be used for various distinct types of Relationship ... this is probably why it is called @Type and not @Role or somesuch.
So I think a better definition might be simply:
relationship type - a URI used to identify the type of a relationship
This relies on the definition for Relationship being correct - and I don't think it is. We have:
relationship -The kind of connection between a source part and a target part in a package. Relationships make the connections between parts directly discoverable without looking at the content in the parts, and without altering the parts themselves. (See also Package Relationships.)
A relationship is not a "kind of" (read "type of") connection, but a connection itself! So I think a better definition would be:
relationship - A connection between a source part and a target part in a package. (See also Package Relationships.)
These changes would fix things up on this DR, I think.
On your other point, I too have surveyed the 405 other uses of "type" in the text and agree they seem ok!
Thanks,
- Alex.
From: Shawn Villaron [mailto:shawnv at microsoft.com]
Sent: 01 April 2010 04:21
To: SC 34 WG4
Cc: Richard Bretschneider
Subject: DR 09-0322 - OPC: Types
Good morning, afternoon and evening,
In going over the DR log I noticed this defect report. On our January 7th teleconference we decided to add a new a new entry for 'relationship type' into the Terms and Definitions section of Part 2:
relationship type - A URI. Identifies the function of a relationship within the package, as defined in the Standard. Format designers may define new relationship types as needed.
I believe we left it with an ask of GB to determine if this was satisfactory. GB folks, any thoughts on if this addresses the initial request?
In the meantime, I've gone through the 405 instances of 'type' in Part 2 looking for ambiguous references ( that is, when it is unclear what type is specifying ). I found that all cases of 'type' were well qualified and unambiguous. As such, I don't think we have anything else to do regarding replacing any instances of 'type' with anything else to provide more clarity.
What do we think about this DR?
Thanks,
shawn
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.vse.cz/pipermail/sc34wg4/attachments/20100401/c29ea2a0/attachment-0001.htm>
More information about the sc34wg4
mailing list