dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [dita] Groups - Proposal 12008 - vocabulary and integration constraints(HTML) (IssueConstraints12008.html) uploaded
- From: Michael Priestley <mpriestl@ca.ibm.com>
- To: "Eliot Kimber" <ekimber@reallysi.com>
- Date: Wed, 22 Aug 2007 09:13:18 -0400
Here's a concrete example:
- I decide as an information architect
that my deliverables need to have short descriptions, because otherwise
my hub linking pages that draw from them look bad.
- so I ask my specializer to implement
a constraint in my schemas to make shortdesc required
- I begin reusing content from other
groups, some of whom have implemented the constraint, some of whom haven't
- when I conref in a topic from a group
that hasn't implemented the constraint, I expect a warning to the effect
that my constraint hasn't been applied to the stuff I'm pulling in - similar
to the warning I would expect when pulling in content that includes domains
that might need to be generalized.
If I don't have a way to signal the
usage of constraints to processors, I have no easy way to get warnings
or errors from my processors.
Same thing as domains, same reasons,
domain checking already done in conref, so not an academic thought.
Michael Priestley
Lead IBM DITA Architect
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25
"Eliot Kimber"
<ekimber@reallysi.com>
08/22/2007 06:19 AM
|
To
| dita@lists.oasis-open.org
|
cc
|
|
Subject
| RE: [dita] Groups - Proposal 12008 -
vocabulary and integration constraints (HTML) (IssueConstraints12008.html)
uploaded |
|
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.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]