[sc34wg3] Explanation in TMCL?

[Lars Marius Garshol]

* Robert Cerny
> 
> "0, *" because the explanation is a text in natural language and not everybody speaks English, so it should be possible to attach an explanation in English and one in French and so on.

Right. :)

> I disagree that creating a useful validation report is outside the scope of constraint language. Overall it is just a minature change (note that my suggestion does not require TMQL) and will overall make TMCL more useable, because it will create better validation reports. It is not more than tmcl:comment or tmcl:see-also. Just that it is really useful :-)

Many things would be useful, yet are outside the scope of TMCL. We really do have to draw the line somewhere in order to be able to finish the thing.

Right now the goal is to come out of the March meeting in Stockholm with the final spec, and the fewer new features we add, the greater our chances of achieving this will be.

> Hmm. I am having troubles understanding the rejection reason. No real notion of error? But what do we have constraints for then? Is there maybe some minutes of the meeting which explains the rejection in more depth?

Unfortunately not, and I wasn't present, but I can try to give a summary of what I imagine was the reasoning.

Early TMCL drafts had an elaborate error-reporting structure with a whole set of information item types for the various errors etc etc. In the end it was felt that this bloated the spec too much compared to the benefit it brought, and so the spec was simplified to the point where all it does is to say whether or not a topic map is valid for a given schema.

So there really is no notion of error beyond the "it is valid" / "it is not valid" distinction. If we are to introduce this occurrence type then suddenly we do have to get into the business of how to report errors, which can actually very complex, and which we'd rather not do.

> As a someone with a very strong practical orientation i think the suggestion is a good, just that i do not see the necessity to make it dependent on TMQL, since the error message can be presented together with the statement that violates the constraint. And this will already make a lot of sense. More sense than some generic blabla, which you can always fall back to if there is no custom error message for the constraint.

I agree the suggestion is good, but I think you can equally well implement this without that occurrence type being included in the standard.

--Lars M.
http://www.garshol.priv.no/tmphoto/
http://www.garshol.priv.no/blog/