[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [xtm-wg] Mapping of XTM syntax to the Conceptual Model
First a general comment: It cannot be underestimated how important it is that the mapping between the CM and XTM is well understood and complete and how equally important it is that the mapping between the CM and ISO 13250 is. Without such a mapping, be prepared for applications which support ISO 13250 at the expense of true XTM support and vice-versa. So I must start with a thank you to Daniel for this document. I do have some queries and comments regarding this document. Quotes from Daniel's mapping document are preceeded with a > at the start of the line. > <!-- association: Topic Association --> > <!ELEMENT association (associationSpec? , instanceOf* , scope? , (member+ | role+ )*)> > <!ATTLIST association id ID #REQUIRED > and later: > The <member> element is syntactic shorthand for a <role> element and its <player> subelement. > It can only be used when there is no need to specify the Topic that is the Role itself. > > Note: This is only included to ensure backward compatibility with topic maps that were created > on the basis of the Core Deliverables presented on 4 December 2000 in Washington. If the > requirement for such compatibility is dropped, then the <member> element can be droped also. I would be in favour of dropping <member> from the content model of <association> and from the DTD. <role> performs the job admirably. However I do have a question about the content model of role: > <!ELEMENT role (roleSpec? , (topicRef | resourceRef | subjectIndicatorRef ) , player* )> What is the (topicRef | resourceRef | subjectIndicatorRef ) part of the content model refering to ? Is it a shorthand to prevent having to write a nested <player> element ? If so, I would ask for it to be dropped from the content model of <role>. Finally, I would like to note that I have made some additional comments with regards to the element definitions presented at this point in the proposal in response to Holger's comments (email subject: RE: [xtm-wg] Comments on XTM Spec 1.0 Next, with respect to the <topicRef> sub element Daniel says: >Note: To allow this to work, the restriction stated in the DTD of 4 December 2000 that a ><topicRef> element can only reference a <topic> element, needs to be relaxed. It also needs >to be allowed to reference an element whose element type is represents a subtype of Topic. > >It has been argued that the <subjectIndicatorRef> element can be used instead of the <topicRef> >element for this purpose, since the Subject indicated by an XTM element is always the Subject >of the topic represented by that element, and therefore the Topics themselves are the same. >The problem with this approach is that it requires the system to resolve the xlink:href to >find a Resource, then ascertain whether that Resource is or is not an element in an XTM >document, in order to know how to process it. It would be far more efficient, and consistent >with the previous decision that things that are different in kind should be expressed through >different syntax, to state that the <topicRef> element should always be used to reference an >XTM element that directly represents the relevant Topic, and to use the <subjectIndicatorRef> >element when the Topic is being referenced indirectly, by identifying its Subject through a >Subject Descriptor. I agree with Daniel's assertion that <associationSpec> and <roleSpec> need something more tightly defined than <subjectIndicatorRef> to locate their respective template objects or at the very least require that the reftype of the <subjectIndicatorRef> be suitably constrained for those elements. The current XTM specification requires that a conformant application chase down every subjectIndicatorRef to determine whether or not it is a <topic> - a considerable overhead in a web-based environment. The <topicRef> element already provides the semantics that are covered by this 'special case' of subjectIndicatorRef and it seems to me that if I use a <topicRef> I want the resource indicated by that element to be located and treated as a topic (and perhaps merged with the topic which references it). If I use a <subjectIndicatorRef> I *do not* want the resource I point to to ever be merged with the topic from which it is referenced regardless of whether or not it is a <topic> element. Where I have some reservations however is in the 'overloading' of <topicRef> to point to <association> and <role> elements. I understand the rationale from the CM perspective, but from a syntax perspective I would much rather that roleSpec and associationSpec elements by simple XLinks in their own right with their own specific reftypes. i.e. <!ATTLIST roleSpec id ID #IMPLIED xlink:type NMTOKEN #FIXED 'simple' xlink:href CDATA #REQUIRED> I feel that this is less verbose and computationally cleaner than overloading <topicRef>. With respect to resourceRef, Daniel writes: > The <resourceRef> subelement of any element other than a <topic> element is syntactic > shorthand for a <topicRef> element pointing to a <topic> element that itself has that > <resourceRef> as a subelement of its <subjectIdentity> subelement. > > Note: It is difficult to see how what a <resourceRef> subelement on <scope> would mean. > What does it mean to be in the scope of a resource? Ditto for a <resourceRef> subelement on > <mergeMap>, since if a <resourceRef> makes no sense on a <scope>, it makes no sense to add > it to a <scope> when merging. I had assumed that <resourceRef> in a <scope> meant more or less exactly as described - and that the 'implicit' topic generated as a result of processing the resourceRef may or may not merge with an existing topic by the subject-based merging rule. My understanding is that the reason that <resourceRef> is not a child of other 'topic identifying' elements such as <instanceOf> is that it makes no sense to use a topic who's subject is a resource for the purposes of specifying a class of topic map constructs. However, this raises the question of whether or not it should be a reportable error for <instanceOf> to refer to a topic (e.g. via <topicRef>) which has a subject constituting resource. Cheers, Kal > -----Original Message----- > From: Daniel Rivers-Moore [mailto:daniel.rivers-moore@rivcom.com] > Sent: 08 January 2001 19:42 > To: 'xtm-wg@egroups.com' > Subject: [xtm-wg] Mapping of XTM syntax to the Conceptual Model > > > I have now prepared a first draft of the mapping from XTM syntax to the > Conceptual Model. > > It is attached as an htm file. > > <<20010108.drm.ConceptualModelToSyntaxMapping.htm>> > > The mapping raises a number of issues, some of which I had > already raised in > previous messages to this list. They can easily be identified within the > document when it is displayed by the browser, as they will appear in red > type. > > After review of this draft, and any amendments to it and/or the DTD that > result from that review, it would be important to incorporate into it a > statement of the topic merging rules, expressed simply in terms > of what sets > of elements map to a single Topic, rather than in terms of processing - in > other words a declarative rather than a procedural statement of > the merging > rules. > > Comments please. > > Daniel > > > > To Post a message, send it to: xtm-wg@eGroups.com > > To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com > 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