[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] Groups - Proposal 12008 - vocabulary and integrationconstraints (HTML) (IssueConstraints12008.html) uploaded
From: Deborah_Pickett@moldflow.com
[mailto:Deborah_Pickett@moldflow.com]
[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. 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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]