RE: [dita] Groups - Proposal 12008 - vocabulary and integration constraints(HTML) (IssueConstraints12008.html) uploaded

[Erik Hennum <ehennum@us.ibm.com>]

Hi, Eliot and Tony:

"Tony Self" <tself@hyperwrite.com> wrote on 08/22/2007 04:58:17 PM:
>
> 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.

The goal is to identify the constriant so a process can check whether a
conref is safe before resolving the conref.

Obviously, it's better to verify that the conref will work at editing time if possible,
but the output processor should also be able to verify the conref, especially
if you are consuming content supplied dynamically by other content creators.


"Eliot Kimber" <ekimber@reallysi.com> wrote on 08/22/2007 03:19:28 AM:
>
> The specification of constraints implies a requirement to check or
> enforce those constraints in some processing contexts.

That's true in general but not of this proposal because this proposal doesn't
introduce a constraints language. Perhaps the term "constraints" created
the wrong expectation.

The proposal declares _which_ elements have been constrained. There's
no attempt to describe the applied constraint.

To pick up one of the examples:

(topic/section = simpleTopic)

Nothing here indicates what the simpleTopic constraints module did to <section>.
We only know the identity of the module that constrained <section>. That is, the
proposal relies on module names as identifiers for a kind of constraint so designers
can declare which constraints are more restrictive than other constraints.

In relying on module identity to manage compatibility, the constraints attribute
resembles the domains attribute. In managing compatibility at the element
level, the constraints attribute resembles the class attribute.

I'd submit that, in the same way that declaring ancestry with the class attribute
encourages designers think about the rules of specialization, declaring what
was constrained encourages designers think about the rules of restriction and
practice safe constraints instead of introducing additions that will break
interoperability.

> But as expressed through attributes their value is much more limited
> unless editors and validators implement some processing based on
> those attributes.

That's the other main reason for identifying the constrained elements: as Tony
notes, so a conref processor can check whether the referencing element is less
restricted than the referenced element.

To summarize the essential parts of the proposal:

• DITA users have a long-standing request to be able to simplify vocabularies.
  
• Restriction doesn't break interoperability with less constrained versions of the
  same vocabulary or base vocabularies.
  
• Constraints can be implemented entirely with vanilla XML.
  
• The design pattern for vocabulary modules could accomodate constraints
  as pluggable, reusable design modules.

To rephrase Deborah's identification of the main issue:  what is the minimum level 
of declaration needed for automated processors to check interoperability 
of constrained document instances.


Hoping that's useful,


Erik Hennum
ehennum@us.ibm.com