RE: [xtm-wg] Merging proposals uploaded

["Kal Ahmed" <kal@ontopia.net>]

For those who can't get into egroups, the proposal is attached.

Cheers,

Kal

> -----Original Message-----
> From: Kal Ahmed [mailto:kal@ontopia.net]
> Sent: 19 October 2000 11:29
> To: xtm-wg@egroups.com
> Subject: [xtm-wg] Merging proposals uploaded
>
>
> The file
> http://www.egroups.com/files/xtm-wg/Interchange/merge-proposal%2Ehtml
> contains three separate proposals (or at least they are separate
> in my mind
> ;-).
>
> 1) A proposal for the syntax of mergemaps. In fact, this is the proposal
> that was voted on and passed, so this is really a closed issue.
>
> 2) A proposal for the processing model of merging - determining what topic
> maps to merge and what requirements a conformant application must
> adhere to.
>
> 3) A proposal for handling xtmdoc. In my mind, if the AF purpose of xtmdoc
> is not to be documented, then the other purpose that it has (i.e.
> packaging
> multiple topicmaps) must be documented, including the expected processing
> model. I think that there is also a need for ensuring that the
> packaging and
> unpackaging can actually be done simply. If the other purpose of xtmdoc is
> to be documented (and I for one am not sure that we have the time to do
> this), then this proposal could be safely dropped. BTW, I feel that
> packaging tms is a really weak argument considering that the merging and
> scoping mechanisms can be trivially combined to do tm packaging, so this
> proposal is somewhat of a compromise proposal.
>
> Cheers,
>
> Kal
>
>
>
> To Post a message, send it to:   xtm-wg@eGroups.com
>
> To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com
>
>
>

-------------------------- eGroups Sponsor -------------------------~-~>
Get FREE long-distance phone calls on Tellme!
Dial 1-800-555-TELL, say "Phone Booth"
http://click.egroups.com/1/9816/4/_/337252/_/971951580/
---------------------------------------------------------------------_->

To Post a message, send it to:   xtm-wg@eGroups.com

To Unsubscribe, send a blank message to: xtm-wg-unsubscribe@eGroups.com

Topic Map Merging Proposal(s)

Mergemaps syntax: 1

Merging principles: 1

WHAT: 1

WHEN: 2

HOW FAR: 2

UNRESOLVED REFERENCES: 2

THE PROPOSAL 3

XTMDoc Processing 3

Processing cross-references 3

Processing multiple topic maps 3

---

Proposal 1 - Mergemaps syntax:

<!-- NOTE: All names are up for grabs. The use of XLink is also up for grabs -->

        <!ELEMENT mergemap  (addscope+)>

        <!ATTLIST mergemap

               id     ID     #IMPLIED

               themes CDATA  #IMPLIED

               href   CDATA  #REQUIRED   >

        <!ELEMENT addscope EMPTY>

        <!ATTLIST addscope

               id      ID    #IMPLIED

               themes  CDATA #REQUIRED

               href    CDATA #REQUIRED   >

mergemap.-themes- identifies the set of themes to be added to the scopes of all characteristic assignments in the merged topic map.
mergemap.-href- locates the topic map to be merged.
addscope.-themes- identifies the set of themes to be added to the scopes of the characteristic assignments identified by the -href- attribute.
addscope.-href- locates the topic map object to receive the additional themes. The themes are added to the scope of the topic map objects defined by the identified element and all of its sub-elements. If the locator points to a whole document, then the themes are added to the root element of the document and all of its sub-elements.

---

Proposal 2 - Merging principles:

NOTE: This description is way more complex than should ever appear in the specification. This is to cater for the fact that we have a number of choices to make and we need some way of putting a handle on each of the issues for a clean discussion. Once the discussion is had and the decision is made, the need for some of these special handles goes away and the definition of the other handles becomes far less complex.

The principles that need to be defined are: WHAT topic maps in the world of all topic maps are to be processed in a given session WHEN (at the latest) an application should process a particular topic map HOW FAR into the recursive loop does this process go.

WHAT:

Some definitions:

·        The 'base topic map' is the hub document of the topic map processing

·        ‘required object set’ is the set of objects existing in topic maps other than the base topic map. The content of this set may be defined in a number of different ways as defined below.

·        The 'candidate set' is the set of topic maps which a conformant application *may* be required to be familiar with. The specification may mandate that the candidate set must be processed by a conformant topic map application. Whether or not the specification will require that the candidate set be merged has no relevance to how the candidate set is defined. The candidate set may be determined in a number of different ways as defined below.

The 'required object set' of a topic map may be defined as either:

• A) The empty set.
• B) Any topic map document or object referenced from a topic map.
• *C) Any topic map document or object referenced from:
• The -instanceOf- attribute of topic
• The -instanceOf- attribute of assoc
• The -role- attribute of occurs or assocrl
• The -scope- attribute of topname, basename, sortname or dispname
• The -scope- attribute of occurs or assocrl
• The -href- attribute of assocrl
• The -href- attribute of occurs if and only if the topic specified in the -role- attribute of that occurs element has as its identity a reserved PSI to be defined by the specification.

The 'candidate set' of topic maps to be processed may be determined in one of two ways

• 1) The empty set.
• 2) The candidate set consists of any topic map referred to from the base topic map or containing an element which is referred to from the base topic map. But then I can't refer to an example of a bad topic map.
• 3) The following maps are the only members of the candidate set:
• a) All topic maps specified in mergemap.-href-
• b) All topic maps containing members of the required object set
  NOTE: This with option A above => only the topic maps specified in mergemap
• *4) The following objects are the only members of the candidate set:
• a) All topic maps specified in mergemap.-href-
• b) All objects in the required object set.

WHEN:

The XTM Specification should provide guidance on if and when a conformant application should be familiar with the content of a member of the candidate set.

• i) All topic maps which are members of the candidate set must be processed before any interaction between the topic map processor and systems built on the processor takes place This is too onerous for light-weight / disconnected topic map applications. e.g. the topic map application that I use to browse my CD-ROM encyclopaedia that has references to an online topic map.
• * ii): The specification makes no requirement about which members of the candidate seta conformant application should be familiar with.

NOTE: Being familiar with a topic map means, amongst other things, knowing enough about that topic map to determine which topics within it are to be merged with topics already processed

HOW FAR:

The Specification should provide guidance for application developers on when to stop doing recursive merges.

• W) Never stop - on processing an eligible member of the candidate set, the results of that processing must be considered to be part of the base topic map and the determination of the candidate set is repeated. This is probably infeasible if the topic maps are ubiquitous.
• X) 1 level - the base topic map is never modified for the purposes of determining the candidate set. This seems a little too arbitrary
• Y) Author controlled. Implement some form of BOS control: boslvl, bosspec etc. Too hard to explain? Already do-able with ISO syntax. If you want this, use ISO13250.
• * Z) User/application controlled - a conformant application is required to be capable of at the minimum:
• Determining the candidate set
• Processing a member of the candidate set as required by the client.

UNRESOLVED REFERENCES:

Until they are resolved, all references to topic map objects made from -instanceOf-; -scope- and -href- (on assocrl) attributes resolve to an unnamed, minimally typed (i.e. typed either as ‘topic’ or ‘unresolved topic’) topic with a subject identifier of the unresolved reference.

THE PROPOSAL

Use the options marked with an asterix..

The proposed combination of options means that: The set of topic maps to be merged is rigidly defined in terms of those topic maps that the author explicitly asks for and those that are implicitly required because they either characterise some construct in the base topic map; or play a role in an association in the base topic map. Those topic maps are brought into the application's processing world only if the client of the application requests it. Finally, until a client chooses to resolve the topic map containing a specific object, it always resolves to an unnamed topic with some minimal type and a subject identifier, which is the value of the reference.

---

XTMDoc Processing

The xtmdoc wrapper element requires that mechanisms need to be defined for:

1.      The processing of cross-references between topic maps packaged in an xtmdoc wrapper.

2.      The processing of multiple topic maps in a single document

Processing cross-references

Cross-references are references between topic maps contained in an xtmdoc wrapper. If the purpose of the wrapper is to enable exchange of a package of topic maps, there must be a way to:

1.      Ensure that all object identifiers are unique across all topic maps in the package.

2.      Enable topic maps to be added to a package with a minimal amount of pre-processing

3.      Enable cross-references between topic maps in a package to be resolved with a minimal amount of additional processing

To ensure that object identifiers are unique, a packaging process will be required to prefix all id attribute values in a particular topic map with a value that is unique across all topic maps currently in the package.  The prefix assigned by the packager to each topicmap must be recorded on the wrapper to enable the receiver to strip the values out again. The base url of each topic map must also be recorded on the wrapper to enable the receiver to determine when a reference is located in another topic map in the same package.

This requires a redefinition of the xtmdoc wrapper to include this additional information for each packaged topic map:

        <!ELEMENT xtmdoc (redirect, topicmap)+>

        <!ELEMENT redirect EMPTY>

        <!ATTLIST redirect

               tmid     IDREF #REQUIRED

               tmbase   CDATA #REQUIRED

               idprefix CDATA #REQUIRED>

NOTE: the redirect is implicitly bundled with the topicmap that it applies to. An alternative content model would be (redirect+, topicmap+) – which would require a forward declaration of the prefix and url of each packaged topic map but would also be less robust than the proposed content model and would require an addressing mechanism to associate the redirect with the topicmap to which it applies.

Processing multiple topic maps

The first topic map in an xtmdoc will be treated as the base topic map for processing. Further topic maps in the same package will be processed according to the merging rules set out above.