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: "Tony Self" <tself@hyperwrite.com>
- To: <dita@lists.oasis-open.org>
- Date: Thu, 23 Aug 2007 09:58:17 +1000
So, Michael, in this example, the warning that
"non-constrained" info was being used in a conref should appear in the
editor? I am trying to work out in this context whether "processor" means
the transforming process to produce output, or the schema processor in the
editor.
When the content is processed to output, constraints
should have no impact. If the required shortdesc has already been enforced
during the editing process, the output processor (which knows how to process
shortdescs whether they are included or not) doesn't need to bother doing
anything different.
Have I got this right?
Tony
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]