[sc34wg3] Requirements for the foundational model - level 1

[Lars Marius Garshol]

Hi Martin,

First off: thank you very much for these excellent question. Very good
that someone asks them.

* Requirements draft
|
| 1. The data model shall define all logically relevant aspects of
| topic map information (including all strings and locators). Anything
| that is not explicitly part of the model shall not considered to be
| part of topic maps.

* Martin Bryan
| 
| Who is to decide what is and is not "logically relevant"? 

We are. That is, the line is to be drawn by the data model.

| For example, Sort Names are not considered "logically relevant" by
| the XTM community, but are an explicit logical unit within ISO
| 13250.

They are logically relevant in XTM as well, they are just not
first-class objects. Instead, they are represented as variant names in
a particular scope.

| One of the problems we have been having is that as people try
| to "simplify" the model we are loosing the ability to distinguish
| between data sets that need to be separately managed.  Who is to
| make the decision as to what can and cannot be managed within a
| topic map?

This question I am not sure I understand. Can you elaborate?
 
* Requirements draft
|
| 3. The data model shall be written in such a way that third parties
| can write specifications defining the process of building instances
| of the model from data sources other than the two standardized topic
| map syntaxes.
 
* Martin Bryan
|
| Is ISO 13250 really a standardized syntax? I always thought that one
| of its strengths was the way it was divorced from application
| syntaxes.

It's admittedly a simplification to say that it's a single syntax.  It
is of course a HyTime meta-DTD, but I'm not sure we gain anything by
increasing the precision of this requirement. Would you like us to
change it, or did you just want clarification?
 
* Requirements draft
|
| 2. The foundational model shall be 100% compatible with every aspect
| of the implicit data model of XTM 1.0 that is actually defined in
| the XTM 1.0 specification. This includes annex F.
 
* Martin Bryan
|
| What happens if some aspect of ISO 13250 is not covered by the model
| (e.g.  facets)?

It must still be represented, although perhaps not in the precise form
it takes in the 13250 syntax. So sort and display names become
variants, while facets will most likely be represented using topics
reifying the resources the facet values apply to, and using
associations to represent the assignment of facet value.

So no logically significant aspect of the 13250 model should be lost,
although its representation may be a little unfamiliar.
 
* Requirements draft
|
| 5. The foundational model shall be able to represent all logically
| significant aspects of ISO 13250 topic map documents.
 
* Martin Bryan
|
| Who is to decide on the significance of any 13250 construct?

We are. That is, this line must be drawn as part of the process of
creating the model. We may end up having disagreements over some of
that line-drawing, though I do not really expect so.
 
* Requirements draft
|
| 6. The foundational model shall not contradict any constraints on
| the model laid down by ISO 13250, except in so far as they are
| contradicted by XTM 1.0. In cases of discrepancy XTM 1.0 shall take
| precedence.
 
* Martin Bryan
|
| You cannot really expect me to accept the inflammatory statement in
| the second sentence !!!!!

That's the point of having a requirements document, Martin. You get to
voice your disagreement before someone has spent a month of their life
creating something parts of the community cannot live with. So we're
not expecting you to accept this; we're expecting you to let us know
what you think of it.

It's not obvious to me what the problem with this statement is, so
it would be nice if you could outline the problem as you see it.
 
* Requirements draft
|
| 7. The foundational model shall be 100% compatible with the
| interpretation of the ISO 13250 syntax as defined in ISO 13250.
 
* Martin Bryan
|
| How can this statement (which has my whole-hearted support) be
| reconciled with the previous one?

Good point. It may not be possible, now that you point to it. Our
original intent would probably be reflected by tacking on ", except in
cases where contradictions in the XTM 1.0 model make this impossible."

* Requirements draft
|
| 9. The parsing model shall be defined in terms of the XML Information
| Set.
 
* Martin Bryan
|
| Surely this will be insufficient: we will need to extend the
| Information Set to distiguish between topic map constructs.

It's just the requirement that isn't as clear as it ought to be. What
it's meant to say is that the parsing model will describe how to build
instances of the data model starting from instances of the XML
Information Set. So that's the sense in which it's defined "in terms
of" the infoset.

We'll change the wording here to make that clear.

--Lars M.