Update to Proposal 12008 - vocabulary and integration constraints

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

Hi, Thoughtful TC:

I take Michael's point that it's not enough for conref processors to verify that a specific instance of a referenced document fragment happens to be consistent with a referencing document type. Really, adopters need assurance that any possible instance of a document fragment in a referenced document type will be consistent with the valid destinations in the referencing document type.

I've revised the constraints proposal to move the declaration granularity up to the module level and declare constraints as space-separated modules on the domains attribute.

For convenience, here's the browser-friendly version

http://www.oasis-open.org/apps/org/workgroup/dita/download.php/25090/IssueConstraints12008.html

and here's the authoritative version:

http://www.oasis-open.org/apps/org/workgroup/dita/download.php/25089/IssueConstraints12008.dita

From my perspective, this change has simplified the approach.  Please see what you think.

I can walk through the modified sections quickly at tomorrow's meeting if that would be useful.  I recognize that this revision comes late enough that the earliest possible vote on the proposal would be next week.


Thanks,


Erik Hennum
ehennum@us.ibm.com


Michael Priestley <mpriestl@ca.ibm.com> wrote on 08/23/2007 09:05:40 AM:

> 
> 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.