RE: [xtm-wg] XTM Processing Model - proposal for requirements

["Kal Ahmed" <kal@techquila.com>]

My comments are inline below.

>
>
> Here are my proposed requirements. Please note that this list will
> only have any value if
>
>   a) people read it closely and fight the bits they don't like,
>
>   b) the actual model document follows it, and
>
>   c) the requirements serve as the basis for arguments about what the
>      model should look like.
>
>
>
> XTM Processing Model - requirements proposal
>
> The XTM processing model shall:
>
>  1. Provide implementors of XTM software with all the information they
>     need to ensure that their implementations are fully interoperable
>     with other implementations.
>
>  2. Describe the data model, or abstract structure, of topic maps.
>

I believe that the XTMPM should describe the data model or abstract
structure of *consistent* topic maps. That is, the XTMPM should say nothing
about the conditions of merging or the processing of mergeMap directives -
these are described in Annex F and should not be repeated in another form
for consistency's sake.


>  3. Describe how to build instances of the model from XTM 1.0
>     documents.
>

Only to the extent that it describes the representation of the syntactic
constructs in the abstract data model and that it describes the effects of
the operations described in Annex F in terms of modifications made to the
abstract data model.

>  4. Describe how to build instances of the model from ISO 13250
>     documents.
>

Again, the effects of merging and processing addthems are covered by the
standard and should not be repeated in the processing model.

>  5. Be specified in exhaustive detail, covering every aspect of topic
>     maps that has model, or logical, significance.
>

Yes, and I would argue that inclusion mechanisms such as addthems and
mergeMap do not fall into this category.

>  6. Be written to be easily and fully comprehensible to implementors
>     with as scope for interpretation as possible.
>

presumably last phrase should be "with as little scope for misinterpretation
as possible".

>  7. Not constrain implementations beyond what is necessary to ensure
>     that they do follow the XTM standard.
>

It should not constrain ISO 13250-based implementations to follow the XTM
standard.

>  8. Describe error situations and how to handle them.
>

What error conditions do you have in mind that are not already covered by
XTM 1.0 or ISO 13250 ?

>  9. Include no optional parts in the model.
>
>  10. Include as few optional processing steps as possible.
>

Cheers,

Kal


------------------------ Yahoo! Groups Sponsor ---------------------~-~>
Do you have 128-bit SSL encryption server security?
Get VeriSign's FREE Guide, "Securing Your
Web Site for Business." Get it now!
http://us.click.yahoo.com/2cW4jC/c.WCAA/bT0EAA/2n6YlB/TM
---------------------------------------------------------------------_->

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

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

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/