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: Deborah_Pickett@moldflow.com
- To: Erik Hennum <ehennum@us.ibm.com>
- Date: Wed, 22 Aug 2007 09:59:52 +1100
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.
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).
--
Deborah Pickett
Information Architect, Moldflow Corporation, Melbourne
Deborah_Pickett@moldflow.com
Erik Hennum <ehennum@us.ibm.com>
22/08/2007 12:49 AM
|
To
| "Grosso, Paul" <pgrosso@ptc.com>
|
cc
| dita@lists.oasis-open.org
|
Subject
| RE: [dita] Groups - Proposal 12008 -
vocabulary and integration constraints (HTML) (IssueConstraints12008.html)
uploaded |
|
Hi, Paul:
DITA is an architecture populated by a vocabulary. The DITA architecture
has always augmented schema languages with the syntax and semantics of
specialization (by which we derive new vocabularies from existing vocabularies)
and pluggability (by which we integrate those vocabularies to make document
types). Those capabilities -- extensibility without sacrificing interoperability
-- are responsible for much of DITA's success.
The constraints proposal expands the capabilties of the architecture. Like
any change, that has both benefits and costs as you note. I would point
out that DITA adopters have been asking for this capability from the start.
Examples of some common constraints that people want to apply:
* Requiring <shortdesc>.
* Disallowing text and phrase elements in <section> and <example>
and their specializations.
* Disallowing nesting of blocks.
* Replacing <prolog> with a specialization without specializing the
topic.
Constraints would also give the TC a straightforward way to resolve the
tension around task. The existing task usefully enforces best practices
for some content but isn't flexibile enough for other content and users.
The TC could relax the content models of task but refactor the task document
type to restore the existing restrictions via a constraint. In this respect,
task provides an example of the design tension between flexibility for
specialization and best practices for authoring and of how constraints
can offer a resolution.
I'd also point out that, because constraints are optional, the proposal
raises the ceiling with little burden on designers who aren't using constraints.
The main cost for those designers is in the DTD implementations, where
designers have to provide entities for each element content model and element
attribute list. (Many non-DITA vocabularies use that design pattern anyway
as a best practice.) The other cost in both DTD and Schema implementations
is the constraints attribute on topic and map, but if you aren't taking
advantage of the capability, that attribute is empty.
So, from my perspective, the benefits vastly exceed the cost, but that
of course is something to discuss.
Thanks,
Erik Hennum
ehennum@us.ibm.com
"Grosso, Paul" <pgrosso@ptc.com> wrote on 08/21/2007 06:25:30
AM:
> If I'm reading this correctly, it sounds like we are augmenting DTD
> constraints with some home brew syntax and semantics that users will
> need to learn and understand and implementors will need to implement.
>
> It sounds to me like some of these more complex proposals are just
> piling completely new concepts on top of an already complex
> application. Am I the only one somewhat concerned with the
> complexity we are adding to DITA?
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]