dita — archive

Groups - Proposal 12008 - vocabulary and integration constraints (HTML) (IssueConstraints12008.html) uploaded

From: Paul Grosso <[email protected]>
To: [email protected]
Date: Tue, 21 Aug 2007 19:31:00 -0000

From: Michael Priestley [mailto:[email protected]] Sent: Tuesday, 2007 August 21 14:02 To: Eliot Kimber Cc: [email protected] 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