[sc34wg3] Explanation in TMCL?

Robert Cerny robert at cerny-online.com
Thu Jan 28 06:00:53 EST 2010

On Jan 28, 2010, at 8:39 AM, Lars Marius Garshol wrote:

> 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.

Totally with you on this one. Eagerly waiting for the next draft. And  
if i need to shut up to speed it up, i will. :) Quiet as a mouse.

>> 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.

Thanks. It makes sense if you already have been down this road.

>> 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.

I agree. And i already did. It is just that the amount of informal  
conventions that are floating around increases and i do feel bad to  
hard code those in the application without a good reason (e.g.  
meaning of languages and role types as scoping topics).


Robert Cerny

Software Development

More information about the sc34wg3 mailing list