OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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



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
Deborah_Pickett@moldflow.com



Erik Hennum <ehennum@us.ibm.com>

08/28/2007 06:25 AM

To
dita@lists.oasis-open.org
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
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.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]