Groups - Proposal 12008 - vocabulary and integration constraints (HTML) (IssueConstraints12008.html) uploaded

From
Date
2007-08-21T16:15:00+00:00
ID
<>
Thread
Groups - Proposal 12008 - vocabulary and integration constraints (HTML) (IssueConstraints12008.html) uploaded

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
[email protected]


"Eliot Kimber" <[email protected]> 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:[email protected]]
> Sent: Tuesday, August 21, 2007 9:26 AM
> To: [email protected]
> 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?

>