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

["Eliot Kimber" <ekimber@reallysi.com>]

From: Deborah_Pickett@moldflow.com [mailto:Deborah_Pickett@moldflow.com]
Sent: Tuesday, August 21, 2007 7:00 PM
To: Erik Hennum
Cc: dita@lists.oasis-open.org; Grosso, Paul
Subject: RE: [dita] Groups - Proposal 12008 - vocabulary and integration constraints (HTML) (IssueConstraints12008.html) uploaded

 

Hi TC,

I should be upfront and say that I've already had a couple of rounds of feedback with Erik over this proposal, so I have had longer to digest it than many.

There are (at least) two aspects to #12008, and though I don't think that they can be entirely separated, it's worth taking note of them as independently as you can.

1. The example XSDs and DTDs demonstrate an increased level of parameterization in the infotype modules (topic.mod, task.mod, hi-d.mod).  Attribute lists are defined as entities; each element has its own entity for the content model.  Fine control over content models with the DITA 1.0 and 1.1 DTDs is quite difficult because of this lack of paramaterization.  I would hope that this aspect isn't controversial, but I could be wrong.

[WEK] I think this increased parameterization is absolutely essential—I guess I didn’t realize it was part of the proposal. I definitely support this aspect.  But this can and should be done whether or not the constraint specification attributes are part of the architecture.
2. The @constraints attribute, and what information it contains (and I suppose how its content is spelled).  This, apparently, *is* controversial.  I'd be curious to know exactly why, given that the existing @domains attribute doesn't cause consternation (that I know about).

The domains= attribute preexisted DITA 1.0 and was therefore just a rule. Plus it’s simple enough and the utility of it as at least documentation is clear enough: you’d like to be able to quickly tell what domains an instance uses in case you need to configure a processor or something. Fair enough.

But constraints are another kettle of fish: the specification of constraints implies a requirement to check or enforce those constraints in some processing contexts. Constraint languages are complex (I’ve been involved with a number of them over my career) and implementing constraint checking is complex. The specification development cost alone of any sort of useful constraint language will be high. For an editor vendor like PTC or Just Systems, the potential implementation cost will be high. From a DITA user standpoint, the cost of having to learn, understand, and apply constraints will be high. Since the practical benefit as far as I can tell accrues from the work done at the DTD or schema level, it calls into question the value of also specifying the constraints as attributes.

Michael says that there is high value in being able to specify these constraints. If they are expressed at the DTD or schema level then I agree 100% because obviously they will enable much greater control that authors need and want.

But as expressed through attributes their value is much more limited unless editors and validators implement some processing based on those attributes. If they aren’t processed then they’re just documentation and I think it would be hard to argue that enabling instance-bound documentation is really that compelling. The only case where having that documentation extant in the instance would be useful would be when you’re presented with documents with no associated DTD or schema but it seems highly unlikely that such documents would be involved in an authoring process since few people would develop a system that supported authoring but didn’t involve DTDs or schemas. Rather, such documents are only likely to be consumed by processors that don’t need to care about validation at that level—they need only check the DITA-level or specialization-specific constraints that are important to the processing at hand, that is, validation by failure.

I’m also sensitive to putting into standards things that will make the standard harder to understand and teach—a hard lesson learned from HyTime and SGML. I put every feature through the “how would I address this feature in my DITA class?” test.  DITA is already hard enough for people to learn, understand, and apply.

Cheers,

E.