Fw: [dita] Groups - Proposal 12008 - vocabulary and integration constraints(HTML) (IssueConstraints12008.html) uploaded

PS: I am absolutely in sympathy with
your drive to keep DITA simple, and I agree that any feature has to be
in or not based on a cost-benefit analysis, with any extra complexity for
specializers definitely landing in the cost column. 

If there's a way to simplify the proposal
I'm eager to find it - but I do think the proposal has considerable usefulness,
and do think the current benefits do outweigh the costs.

Michael Priestley

Lead IBM DITA Architect



http://dita.xml.org/blog/25
----- Forwarded by Michael
Priestley/Toronto/IBM on 08/21/2007 09:56 PM -----



Michael Priestley/Toronto/IBM@IBMCA

08/21/2007 03:44 PM




To
"Grosso, Paul" <>


cc



Subject
RE: [dita] Groups - Proposal 12008 -
vocabulary and integration constraints (HTML) (IssueConstraints12008.html)
uploaded










So I can better understand your position:



- are you advocating that specializers should simply be unable to eg make
shortdesc required without specialization, or replace generic elements
with more specialized ones, or include only some elements from a domain?



- or are you advocating that they should be able to, and we simply accept
that constraints will not be recognized by conref or other dita-aware processes,
so if group A imposes a constraint on their own content there is no way
for them to check whether that same constraint has been applied to the
content they want to reuse without human intervention?



Michael Priestley

Lead IBM DITA Architect



http://dita.xml.org/blog/25





"Grosso, Paul"
<> 
08/21/2007 03:26 PM






To
<>



cc



Subject
RE: [dita] Groups - Proposal 12008 -
vocabulary and integration constraints (HTML) (IssueConstraints12008.html)
uploaded














                From: Michael Priestley
[mailto:]

                Sent: Tuesday,
2007 August 21 14:02

                To: Eliot Kimber

                Cc: 

                Subject: RE: [dita]
Groups - Proposal 12008 - vocabulary and

integration constraints (HTML) (IssueConstraints12008.html) uploaded

                

                I think this is
exactly parallel to the domains attribute,

                and serves a parallel
purpose - communicating constraints  

                for those processes
that care. We've established previously  

                that you generally
don't care, but that others do :-)

                

                We can have yet
again the argument about how or why some  

                companies want
to compare constraints when reusing (ie I  

                want to know if
you're allowing things that will blow up  

                my processor).
But we got nowhere last time.


________________________________


Fair enough.  So how are we going to get anywhere this time?


Do we just let anyone add any amount of complexity to

the DITA spec because someone thinks it's useful to

some audience (almost anything is going to be [at least

perceived to be] useful to someone in some circumstance)?


Or are we willing to say, some people care about some

things and others don't, but we all care about avoiding

making the DITA standard so complex that it buckles under

its own weight, so we all need to evaluate the cost-benefit

of each proposal, and some of us are going to decide the

cost of added complexity is not worth the benefit *as we

perceive it*, so it is perfectly acceptable to vote against

a given proposal on such grounds?


I fear the road we're on is going to make SGML, HyTime,

DSSSL, FOSI, XML Schema, and XSL-FO all look simple in

comparison (yes, I've worked on all those specs and maybe

it's because I have the scars to prove it that I'm trying

to keep DITA from following in the same path).


paul