 | Home |
| Tutorials |
| Features |
| Services |
| Impressum |
   |
TMSS Constraints
The question arises how Topic Map documents have to be composed to be recognized as valid TMSS documents. In the same way as the XML universe uses a schema language to define a content model, we will have to use a constraint language for Topic Maps to model what structure a map must expose to be processable by a TMSS-RSS converter.
For this purpose we peruse AsTMa!, a draft for a TMCL. AsTMa! is an extension of AsTMa= adding pattern matching and logic with quantification. To make it appear less impressive let us look at one example:
exists [ * (channel) ]Here we prescribed that within a map there must exist at least one topic of type channel. The pattern
* (channel)may be familiar to AsTMa= users. The only difference to the authoring language, though, is that AsTMa! allows wildcards like * in a couple of places where normally text, URIs or topic ids would have to be. In our case we are not interested in the exact topic id of the channel. The only important aspect is that it must be a channel.
The channel topic itself is also defined within the constraint, in the same way as channel-item, channel-image and other channel related concepts. These topics form the base vocabulary of the constraint. By themselves, they do not impose any restriction.
Revisiting our constraint, we notice that there is room for improvement:
exists{1} [ * (channel) ] {"The channel is missing"}
First we have narrowed down the constraint to allow and enforce only exactly one topic
within any map which claims to be TMSS conformant. The text in curly brackets can be displayed during
exception handling to a human user in case the constraint is violated.
Along the same lines we may state that there may be any number of channel items:
exists{0,} [ * (channel-item) ]
The quantification exists{0,1} borrows from the extended regular expression
syntax in that {0,} means match 0 to any number of times.
The alert reader may wonder what the above actually accomplishes: Every map will contain 0 or more channel items. What we really want to express is that we would like to see at least one, whereas it is not erroneous by itself to have no item:
suggested exists{1,} [ * (channel-item) ] {"No channel item found"}
The text within curly brackets is only meant as warning in case the map does not contain any
item.
The suggested operator is also useful in those cases where we would like topics to have some minimal information. As one example, we want our channel to contain at least a name, a description and the URL to download channel information:
every $t [ * (channel) ]
=> suggested exists $t [ bn : *
in (description): *
oc (download) : * ]
{"Information on channel incomplete"}
This shows a very typical construction for AsTMa!: First we identify those topics for which we plan
to impose more restrictions. Once we have identified all of them with the every operator,
the variable $t is bound to all of them in turn. In turn means that for every such binding
the followup clause after => is evaluated. Since we used the keyword suggested
here any violation will only raise a warning. In effect, we will see that warning if our channel topic misses
either a base name, an inline (resourceData) description or the download URL.
With the same technique we can proclare that every channel item must belong to a channel:
every [ $i (channel-item) ]
=> exists [ $c (channel) ]
=> exists [ (belongs-to)
item : $i
channel: $c ]
{"An item must be associated with a channel"}
Now we have first identified an item and have bound the topic id of this match to the variable $i.
For all of these matches we look for the channel topic and bind it to $c. We do not bother about
several of such topics because an earlier constraint already forbids this. With both variables bound we now look for
the existence of an association of type belongs-to. There must be one and the item and
the channel must play the corresponding roles. Otherwise the constraint would be violated.
| | |