Re: [dita] Update to Proposal 12008 - vocabulary and integrationconstraints

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

Hi, Deborah:

I couldn't find the quoted phrase, so I may be answering the wrong question,
but constraints on a task element wouldn't invalidate conrefs to topic content.

Let's say a document has a constrained task and an unconstrained topic:

... (topic) (topic task noPrereq-c)

That document can conref from a document with no task and a constrained
topic:

... (topic shortdescReq-c) (topic noRelLink-c) (topic simpleSection-c)

The conref operation is allowed because the topic module is less
constrained in the referencing document and task elements don't appear
in the referenced document and thus can't be conreffed into the referencing
document. The rule applies that conref is valid with a superset of
vocabularies and a subset of constraints.

To put it another way, the constraint on task simply removes some of the
contexts where a writer could have conreffed topic elements. It doesn't
alter the content of any topic element and thus doesn't invalidate conrefs
to topic elements.

On the general issue of setting up a bucket document, you'd apply
as many of your constraints as possible on the topic type.

In the example from the proposal, you could set up a topic with
shortdescReq, noRelLink, and simpleSection constraints. Content from the
bucket topic can then be conreffed into any document where the topic
vocabulary has those constraints or a subset of those constraints.

Similarly, if you needed to conref task elements (for instance <prereq>
boilerplate), you could set up a task with the shortdescTaskReq, noTaskRelLink,
and simpleTaskSection constraints so writers could conref the boilerplate into tasks.

If you need boilerplate content that's not allowed by a constraint, you have
to create a less constrained bucket -- but that's a good thing, because that
declarations manages which documents can safely use that boilerplate. For
instance, if you need to have a boilerplate <section> that contains text, it won't
be valid in documents with the simpleSection constraint, so the architecture
invalidates such conrefs while allowing valid conrefs.


Thanks for pushing on this issue -- an important one to hash out.


Erik Hennum
ehennum@us.ibm.com


Deborah_Pickett@moldflow.com wrote on 08/27/2007 09:09:32 PM:
>
> > 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.

>
> Erik Hennum <ehennum@us.ibm.com>
> 08/28/2007 06:25 AM
>
> For convenience, here's the browser-friendly version
> http://www.oasis-open.org/apps/org/workgroup/dita/download.php/25090/IssueConstraints12008.html