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
Erik Hennum <>
08/28/2007 06:25 AM
To
cc
Subject
[dita] Update to Proposal 12008 - vocabulary
and integration constraints
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
Michael Priestley <> 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.
