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: Erik Hennum <ehennum@us.ibm.com>
- To: "Eliot Kimber" <ekimber@reallysi.com>
- Date: Tue, 21 Aug 2007 09:11:00 -0700
Hi, Eliot:
The proposal leverages standard DTD and Schema capabilities to implement the constraints (with content model parameters in DTD and with class redefines in Schema for constraints on content models). That is, the validation of constrained document instances is plain old XML.
The concern is that about what happens if those implemented constraints aren't declared and managed. If they aren't recognized by the DITA architecture, the design is an unknown customization, the content is no longer DITA content, so the interoperability warranty is broken.
Instead, the proposal declares and manages the set of safe customizations so that
- The content conforming to a customized design can still be regarded as DITA content
- The customizations are pluggable into DITA document types and reusable across document types (including across organization boundaries)
- Processors can recognize customizations and detect when customized content is compatible with other DITA designs (customized or not)
Hoping that clarifies,
Erik Hennum
ehennum@us.ibm.com
"Eliot Kimber" <ekimber@reallysi.com> wrote on 08/21/2007 08:18:07 AM:
> I tend to agree with Paul on this one. I’m having a hard time seeing
> how this is doing anything that can’t be done simply by providing
> content model parameters for each element type, which can then be
> tuned on a per-shell basis to impose whatever constraints are desired.
>
>
>
> From: Grosso, Paul [mailto:pgrosso@ptc.com]
> Sent: Tuesday, August 21, 2007 9:26 AM
> To: dita@lists.oasis-open.org
> Subject: RE: [dita] Groups - Proposal 12008 - vocabulary and
> integration constraints (HTML) (IssueConstraints12008.html) uploaded
>
> 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]