dita — archive
Groups - Proposal 12008 - vocabulary and integration constraints (HTML) (IssueConstraints12008.html) uploaded
Hi Erik,
> any possible instance of a document fragment in a referenced document type will be consistent with the valid destinations in the referencing document type.
How well does that play with the common "bucket of strings" approach to storing reusable phrases? That is, I have a <topic> with some scaffolding to allow me to define a bunch of <ph> elements with IDs, and I pull the strings into my other <topic>s, <concept>s, <task>s and so on. If a task is constrained in some way that doesn't affect <ph> elements, must I still mention the constraint in the bucket-of-strings file (which isn't even a <task>)?
It's also unclear to me whether this has any impact on generalize-during-conref processing. I think it must; there are tricky quantum-tunnel-esque cases, like a topic that doesn't include hi-d using a <ph> to pull a <b> from a topic that replaces <ph> with its domain specializations.
--
Deborah Pickett
Information Architect, Moldflow Corporation, Melbourne
[email protected]
| Erik Hennum <[email protected]>
08/28/2007 06:25 AM |
|
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
[email protected]
Michael Priestley <[email protected]> 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.