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

[Michael Priestley <mpriestl@ca.ibm.com>]

A few radical thoughts:
1) the current level of granularity
(being able to compare constraints on a per-element basis) may not actually
buy us as much as we thought - for example, if we know only <section>
has been constrained, we still don't know whether other elements include
<section>, and so can't tell whether there is a potential for indirect
inclusion of inappropriately constrained content. In other words, because
processes like conref don't know the hierarchy of elements in a topic,
they can only test constraints on a global (per-document/topic) basis anyway.

2) once we sacrifice the granularity,
it's looking like named constraint packages might be enough - it might
be good practice to give the packages descriptive names, like "simplesection",
for the sake of maintainers/specializers - but we wouldn't need to list
every constraint by name in a given package

3) we could then consider treating each
constraint package simply as a domain that restricts either base topic
or the domain being integrated. In other words, we could simplify the syntax
drastically and get rid of the constraints attribute.

Examples:
domains="(topic hi-d myhalf-c)
(topic hi-d nonestingbold-c)"
domains="(topic hi-d replaceph-c)"

From a processors' perspective, all
three domain packages tell us the same thing: we're incorporating the highlighting
domain in a constrained way (actually applying three separate constraint
packages to the integration of the domain)

There would still need to be changes
to processing logic though - the existing logic for domains would contradict
the logic we need for constraints.

For example:
<topic id="abc" domains="(topic
hi-d)"> has a conref to <topic id="xyz" domains="(topic)"
means abc can conref content from xyz
safely, because xyz has a subset of allowable elements 
but xyz can only conref content from
abc through generalization of any found hi-d elements

<topic id="abc" domains="(topic
hi-d replaceph-c)" has a conref to <topic id="xyz" domains="(topic
hi-d)"
means abc cannot conref content from
xyz safely, because xyz has a superset of allowable elements (it still
allows ph)
but xyz can conref content from abc
safely because abc has selected a subset of what's allowed in xyz.

I don't know if that's more confusing
or less. We'd simplify the notation (much less overhead for maintenance
and for human interpretation) but increase the complexity of the comparison
logic.

Michael Priestley
Lead IBM DITA Architect 
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25

Erik Hennum <ehennum@us.ibm.com>

08/22/2007 08:36 PM

To	<tself@hyperwrite.com>
cc	dita@lists.oasis-open.org
Subject	RE: [dita] Groups - Proposal 12008 - vocabulary and integration constraints (HTML) (IssueConstraints12008.html) uploaded

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