Re: [xtm-wg] Simplified requirements

[Lars Marius Garshol <larsga@garshol.priv.no>]

* Sam Hunting
|
| Here is a list of requirements for the PM that I believe meets Lars
| desires,

I'm not sure that it does, but let's examine it in detail to find out.

| 1.  The PM shall be formal and concise. 

While both of these should be goals, I don't think this is enough.
In my list I put this as follows:

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

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

I think this is better because:

 - it says that all aspects should be covered (not in your list)

 - it says that there should be no room for interpretation (what
   formality is meant to achieve, but I believe it is better to list
   the goal than the means to it)

What I have left out is conciseness, but I would be happy for that to
be added back in.

| 2.  The PM should be prepared quickly. 

To me, this is only a goal in so far as it does not detract from the
other goals, but I do of course agree that no unnecessary delays
should be suffered.

| 3.  The PM shall support a wide variety of applications. 

This statement I think is too vague. What _is_ a wide variety of
applications? How do you know when you've added something to the spec
that violates this? Also, the PM can now very well constrain
applications to use a specific implementation approach without
violating this requirement.

I think the intent is the same as my #7 below, but that the wording is
so fuzzy as to obscure that.

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


| 4.  The implementor shall find it easy to write programs that
|     conform to the PM. 

This is not achievable. Both deserializing XTM documents and
especially merging is difficult, and no amount of wishing will make it
otherwise. So this goal should just be taken out, or be replaced by
something that says

  4. The PM should not make XTM processing unnecessarily hard.

or words to that effect.

| 5.  The number of optional features in the PM should be kept
|     to the absolute minimum, ideally zero. 

I'm not sure if we really disagree here, but XTM already has features
that are optional, in the sense that they allow you to do things in
more than one way. Whether that counts as optional I don't know, so
perhaps this statement should be deambiguified in that respect.

It was because of these optional features that I split this
requirement into two pieces:

 9. Include no optional parts in the model.

 10. Include as few optional processing steps as possible.
 
| 6.  PM documentation should be clear. 

Well, yes. I think this belongs with #1, though.

| 7.  The design of the PM shall consider interoperabilty of XTM
|     documents of paramount importance.

This is again too vague, I think. How do you know if the design of the
PM violated this or not? (BTW, I would say that using the PM to
explore RDF alignment, or at least allowing that consideration to
affect the specification, _would_ violate this requirement.)

I wrote this as:

 1. Provide implementors of XTM software with all the information they
    need to ensure that their implementations are fully interoperable
    with other implementations.

instead, which I intended should make the goal of the PM clear.


The following points are not addressed by your list at all:

 2. Describe the data model, or abstract structure, of topic maps.
 
 3. Describe how to build instances of the model from XTM 1.0
    documents.
 
 4. Describe how to build instances of the model from ISO 13250
    documents.
 
 8. Describe error situations and how to handle them.


| I honestly don't understand the controversy on "formal and concise."

There is no controversy on it that I know of. I don't consider graphs
to be a formalism any more than the infoset approach is. IDL, EXPRESS,
ORM and UML are all formalisms.

| This is right out of XML 1.0. 

This is a different spec. What was appropriate for XML 1.0 need not be
for XTMP 1.0.

| Can anyone argue that the productions in XML 1.0 are not useful --
| particularly for ensuring interoperability?

Certainly not, but I can argue that they have no place in XTM

--Lars M.


------------------------ 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/EVNB7A/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/