[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [xtm-wg] [xtm-cms] [xtm-ss] DTD for conceptual model
Given that I had a model I tried to knock up a DTD that provided interchange. I tried to capture some of the constraints that were in the model. The are interesting issue around the area of predefined topic assocs - such as topic occuurence. The model shows distinct constraints on it, but these are hard to capture in a DTD without introducing extra elements. I did this early this morning so please ignore my DTD syntax errors. cheers Graham gdm@empolis.co.uk ________________________________________________________________________ This message has been checked for all known viruses, by Star Internet, delivered through the MessageLabs Virus Control Centre. For further information visit: http://www.star.net.uk/stats.asp -------------------------- eGroups Sponsor -------------------------~-~> eLerts It's Easy. It's Fun. Best of All, it's Free! http://click.egroups.com/1/9699/1/_/337252/_/973587085/ ---------------------------------------------------------------------_-> To Post a message, send it to: xtm-wg@eGroups.com To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com
<html> <body> <h2>Appendix A</h2> <p>This appendix provides a DTD that could be used to describe the model presented in the main part of this document.</p> <p>It is interesting to note that the areas of the model have been simplified and yet made more expressive, such as context, also enable the production of a more regular syntax. e.g. the refernce to a single context entity means that the link to that can be described syntactically as a simple reference, unlike 13250 which used the loc refs structure which was alien to XML and XLink.</p> <pre> <!-- DTD for representation of XTM Model : Nov 2000 --> <!-- topicmap contains many topics --> <!ELEMENT topicmap (topic)*> <!-- topic contains many names and has an XML ID which is unique within the instance. --> <!ELEMENT topic (name)*> <!ATTLIST topic ID ID #REQUIRED> <!-- topic association contains two topic locators and optionally has a contextref. As topic association is a subclass of topic it must also have the names construct and ID attribute. (Please tidy me and use an entity.) --> <!ELEMENT topicassoc (topiclocator, topiclocator, name*) <!ATTLIST topicassoc xlink:link #FIXED "exended" contextref CDATA #IMPLIED ID ID #REQUIRED> <!-- topic locator resolves to a topic through the topicref. The roleref and arcref are primarily intended for use by template topic associations but can arbitrarily be applied to any topiclacator. The roleref defines the the role a topic will play in the association. The arcref defines the nature of the arc between the two topics within the association. --> <!ELEMENT topiclocator EMPTY> <!ATTLIST xlink:link #FIXED "locator" topicref CDATA #REQUIRED roleref CDATA #IMPLIED arcdescref CDATA #IMPLIED> <!-- the concept of topic occurrence is acheived through a number of small patterns, introducing ideas such as resourcedtopic, resourcedtopiclocator and resourcelocators. TopicOccurrence is defined as being a built in association class. The PSD for topic occurrence is ... PLEASE DECIDE and COMPLETE XXXXX e.g. urn:xtm:www.topicmaps.org:topicoccurrence also required are predefine topics such as topic and occurrence which are used to fix the roles PSD topic urn:xtm:www.topicmaps.org:topic PSD occurrence urn:xtm:www.topicmaps.org:occurrence Coonstraint: DTD just isnt powerful enough to describe the constraint withour introducing alot of syntax. The contraint is that the identity of this topic is the topicoccurrence urn, that the rolerefs of the locators are topic urn and occurrence urn. Given this we probably dont need to even define topic occurrence in this syntax. Just use standard associations with the appropriate PSDs. However I have included the additional verbose version which could be used. --> <!ELEMENT topicoccurrence (topicoccurrencelocator, occurrencelocator, name*)> <!ATTLIST topicoccurrence xlink:link #FIXED "exended" contextref CDATA #IMPLIED ID ID #REQUIRED> <!ELEMENT topicoccurrencelocator EMPTY> <!ATTLIST xlink:link #FIXED "locator" topicref CDATA #REQUIRED roleref #FIXED "urn:....:topic" arcdescref #FIXED "urn:....:has_occurrence"> <!ELEMENT occurrencelocator EMPTY> <!ATTLIST xlink:link #FIXED "locator" resourcetopicref CDATA #REQUIRED roleref #FIXED "urn:....:occurrence" arcdescref #FIXED "urn:....:is_occurrence_for_topic"> <!-- while the structure above may be unecessary the resourcedtopic structure is required in order to provide a topic that can represent resources in the real world. Resourced topics are proxies for resources such as 'http://www.empolis.com/graham_moore.html', another way is to say that they are the topic for the subject that IS that html file. --> <!ELEMENT resourcedtopic (name*, resourcelocator*)> <!ATTLIST resourcedtopic ID ID #REQUIRED> <!ELEMENT resourcelocator EMPTY> <!ATTLIST xlink:link #FIXED "simple" href CDATA #REQUIRED> <!-- class subclass/ class instance/ identity are all of a similar form for which verbose syntax could be used. DTD are *very poor* for describing any half sophisticated model! --> <!-- context is a refinement of topic that can contain a set of simpletopiclocators. Making context a first class concept enables global and well identifed context to be re-used and published. There might be a case here for context to be an extended link - as it acting as a grouping? --> <!ELEMENT context (name*, simpletopiclocator*)> <!ATTLIST context ID ID #REQUIRED> <!ELEMENT simpletopiclocator EMPTY> <!ATTLIST xlink:link #FIXED "simple" topicref CDATA #REQUIRED> </pre> </html>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC