[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [xtm-wg] 1.0 Spec Comments
In response to Eric's question on the optionality of roleSpec ... roleSpec was introduced when we were discussing the association templating mechanism. It was a pointer to the role object in a template, that determined the "type of involvement" played by a member in the instance association conforming to the template. Given that an association was not required to have a template, it was an optional element. At the time I argued that we needed an additional element, for the role itself (in the instance association), as well as the pointer to the "role-constraints" in the template. However, with the decision not to include templating in version 1.0, the need that I felt for two elements (one for the instance role, one for the template "role-constraining-topic", has gone away. We only have Role (in the conceptual model), and <roleSpec> (in the interchange syntax). The <roleSpec> element references a topic that "specifies the role" that all the topics referenced from within that <member> element play. It therefore does indeed make sense that it be required. I think this is another "erratum" on the DTD... (the other being the <baseName> subelement of <occurrence>, which has been removed, as agreed in Paris). ALSO - Sorry, I'm 30 minutes past the deadline of midnight EST for comments, but please forgive me ... Looking at this I've spotted an error in the diagram of "Association Between Topics" in the Conceptual Model Annex. The central box should be labeled "Role", not "Membership". The text is correct, but the diagram is an older version. Daniel Daniel -----Original Message----- From: Eric Freese [mailto:eric@isogen.com] Sent: 07 February 2001 16:47 To: XTM Working Group (E-mail) Subject: [xtm-wg] 1.0 Spec Comments First of all - kudos to the editors and contributors on this document. I don't recall ever reading a specification that is so complete and understandable at the same time. My comments: STATUS section - I assume this will be updated on the final version. Section 1.3 - not defined subject constituting reference (used in Annex F) subject indicating reference (used in Annex F) Section 2.1 - para starting with "Because associations express..." - Last sentence states "Relationships may involve one, two or more roles. ". However the DTD says that the <roleSpec> subelement is optional. Are these in conflict? Section 2.2.1.3 - list item #2 - should be "via a subject indicator" - not plural Section 2.2.1.6 - 2nd para - Does the topic naming constraint apply if the <subjectIdentity>s are specified and different? Section 2.2.4 - 1st para - Can you have an association with just one topic? First sentence sounds like you can. Section 3.6.1 - 4th para - last sentence Aren't all topics instances of this class (thru transitivity), whether an instanceOf is there or not? Section 3.7.3 - Examples - 1st example There is an extra language topic included which doesn't seem useful there. Section 3.8.1 - 2nd para - last sentence - Aren't all associations instances of this class (thru transitivity), whether an instanceOf is there or not? - Change last three words to association PUBLISHED subject and include all three in the link. Section 3.9.1 - 2nd para - last sentence Aren't all occurrences instances of this class (thru transitivity), whether an instanceOf is there or not? Section 4 - 2nd para This mentions a Processing Model Specification. Does such as document exist? Section 4.4 - 5th bullet This mentions a Processing Model Specification. Does such as document exist? Annex A - If there is such as document as theProcessing Model Specification, it should be added here. Annex B - Explanations of the occurrence indicators and other labels should be added to this section. Annex D - Double check Sam's email address in the DTD. Annex E - - I assume the status will be changed upon publication. - Core concepts section for topic, association and occurrence: remove the phrase "unless otherwise specified" from the resourceData for each Annex F Is there a requirement that the output of a topic map processor must match the input, if no changes are made to the topic map? In other words, is it legal to apply these rules to a topic map document and output it and call the output identical to the input? Example: Can my application convert all instances of the <instanceOf> element to class-instance associations and say that the result is identical to the original document? Semantically identical? Section F.2.3 I assume this means the same set of topic references, not topics. Section F.2.4 - item 4 - reword as follows: The scopes of the associations are equal as defined by the Scope Equality Principle. - create a link back to the explanation of the principle. Section F.2.5 Item 1 - create link back to the explanation of the string equality principle Item 2 - create link back to the explanation of the scope equality principle Section F.2.6 general - create links back to the explanations of the principles being used Item 1 - reword as follows: The URI use to address the occurrences are equivalent as defined by the URI Equality Principle OR the resource data values that are the occurrences are equal as defined by the String Equality Principle Item 2 - how are the topics equal Section F.5.2 general - create links back to the explanations of the principles being used Section F.5.3 - How would differing subject identifiers affect this process? Nothing is said either way. - general - create links back to the explanations of the principles being used - Item 2 - add the word "a" before scope Section F.5.5 - Postcondition Does merging occur when the topics and associations are added? Section F.6.2 - general - create links back to the explanations of the principles being used - needs an example Section F.6.3 - general - create links back to the explanations of the principles being used - Example label is missing and text should not be numbered Section F.6.4 The precondition and postcondition appear to be identical. <!-- **************************************************************** Eric Freese Email: eric@isogen.com Director - Professional Services - Midwest Voice: 651 636 9180 ISOGEN International/DataChannel Fax: 651 636 9191 1611 West County Road B - Suite 204 WWW: www.isogen.com St. Paul, MN 55113 www.datachannel.com ***************************************************************** --> To Post a message, send it to: xtm-wg@eGroups.com To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com ------------------------ Yahoo! Groups Sponsor ---------------------~-~> eGroups is now Yahoo! Groups Click here for more details http://click.egroups.com/1/11231/0/_/337252/_/981611321/ ---------------------------------------------------------------------_-> To Post a message, send it to: xtm-wg@eGroups.com To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC