[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [xtm-wg] XTM Processing Model - proposal for requirements
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/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC