[sc34wg3] New TMCL slides

[Patrick Durusau]

Lars,

Well, no one wants a "mountain of paper" for TMCL but simply parading 
the bugbear of an expanded specification isn't going to help anyone 
decide what should be in or out of TMCL.

Any additional feature is going to expand TMCL but the question is by 
how much and how attractive is the feature to be included?

If you can illustrate or be more specific about what would expand in 
TMCL to meet the request I made, at least then we could argue as to 
whether it was worth the effort or not. With that sort of discussion, it 
could well be that the proposer of any feature decides it is just too 
much to weight for too little gain.

All I know today is that features that support *your* style of 
editing/constraining topic maps are included and features requested by 
others are automatically "corner" cases. I think members of the 
community would be willing to concede features should not be included if 
the decision turned on something other than the likes or dislikes of the 
editors.

If the discussion can revolve around what features gain, cost, and/or 
how the same goal can be achieved differently, then I think the 
questions of added features may have an outcome that will surprise you 
and hopefully hit closer to Graham's goal.

Hope you are having a great day!

Patrick

PS: For example, if your point is that I could have a "suffersFrom" 
association there is the patient role and malady role, hmmm, well, but 
in that case the various diseases would simply be role players wouldn't 
they? Are you saying make the role more generic and use type on the role 
players to make the distinction? Such that I could restrict the playing 
of a generic role to a player with a particular type?

I suppose but I don't concede that Dimitry shouldn't have his case 
unless there is some showing of actual expansion of TMCL as a result. As 
I recall the reason you have offered thus far was that you and Graham 
decided to encourage a particular style of modeling. I seem to recall 
someone wanting to encourage a certain cleanliness in naming practices. 
That didn't work out so well. Yes, a constraint language is always going 
to favor some constraints over others but let's keep that to a minimum.

Lars Marius Garshol wrote:
>
> * Patrick Durusau
>>
>> For example, I currently have a "works-for" relationship with 
>> different types of entities. Or to recall the multidimensional query 
>> requirements I posted yesterday, I am on the way to having a 
>> "diagnosed-with" relationship with different *types* of issues.
>>
>> If I choose to model an association where the type of the other role 
>> player changes as one association type (I can hear Newcomb howling in 
>> the distance) I don't see how that disadvantages you or anyone else.
>
> It doesn't directly. However, there is no need for you to have the 
> association roles change. Instead, you should have different topic 
> types for the different types of issue. That would suffice to record 
> the information.
>
> If we extend TMCL to make it possible to model this particular 
> approach in detail we need to, well, extend TMCL, make it bigger and 
> more complicated. Which means that all TMCL tools will be bigger and 
> more complicated, and there will consequently be fewer of them.
>
> So this does incur a cost for everyone that is very real.
>
> Where we are with TMCL right now is a phase that every standard goes 
> through, which is where the community starts to discover that there is 
> something which the standard does not do. At this point there is 
> generally a rush to ensure that every single corner case and use case 
> is met.
>
> It's funny but somehow everyone wants a small and simple standard, and 
> at the same time no one is ever willing to accept that their pet 
> feature might perhaps be omitted.
>
> So at the stage we are at now generally turns into a rope-pulling 
> contest between the editors, who want a spec small enough that after 
> printing it can still be lifted by a single person, and everyone else, 
> who wants their particular feature supported.
>
> Graham keeps saying that TMCL is meant to meet the 80/20 case, but it 
> will really require a stroke of luck for that to be true once we all 
> return home from Leipzig. At that stage we're more likely to be at 
> 99.99/0.01.
>
>> I suppose part of my reluctance is that I prefer that we enable users 
>> to create their own topic maps using such models and constraints as 
>> they find useful and necessary, with a minimum of forcing views of 
>> "correct" modeling upon them.
>
> My reluctance is to turn TMCL into a paper mountain in the style of 
> ISO 29500.
>
> --Lars M.
> http://www.garshol.priv.no/tmphoto/
> http://www.garshol.priv.no/blog/
>
> _______________________________________________
> sc34wg3 mailing list
> sc34wg3 at isotopicmaps.org
> http://www.isotopicmaps.org/mailman/listinfo/sc34wg3
>

-- 
Patrick Durusau
patrick at durusau.net
Chair, V1 - US TAG to JTC 1/SC 34
Convener, JTC 1/SC 34/WG 3 (Topic Maps)
Editor, OpenDocument Format TC (OASIS), Project Editor ISO/IEC 26300
Co-Editor, ISO/IEC 13250-1, 13250-5 (Topic Maps)