RE: [dita] Why There are Constraints on Conref

[Michael Priestley <mpriestl@ca.ibm.com>]

My primary concern is distinguishing
cases that will break processing. Bringing in other content into a namespace
would almost certainly break processing, since there are no namespaces
currently in DITA, and no tools would know what to do with it. 

If we bring in content via conref, I
think it has to be normal, un-namespaced DITA. Otherwise processes that
don't know what it is (ie all existing processes) will either ignore the
content (effectively deleting the reused content), or throw errors and
break.

I think the first question is how big
is the problem we're actually talking about:
- how common will it be for two groups
to have different rules around what goes in a task, and still need to share
content (in both directions)?
- for those different-rules-but-need-to-share
groups, how common will it be for them to want to ignore their own rules
when they are reusing? IE, enforce rules when their authors create content,
but ignore the rules when their authors conref others' content?

You say the worst case is that one group
might need to rewrite content; I actually think that may be quite normal,
and not a worst case at all. Think of an actual example:

- group L has a bunch of loose tasks;
they follow a best practice of conreffing from a loose task type file full
of common content
- group S has a bunch of strict tasks,
and some similar common content, stored in a strict task type file
- the groups agree to merge their common
content, so they can share reuse
- they identify the elements in group
L's ditabase files that are of interest to both teams, and move them into
a new ditabase file that enforces the strict task type
- now group L has two common-content
task files: one that uses the loose task type, with elements that only
they use, and one that uses the strict task type, which both can use

Because group L moved the cross-group
content into the stricter doctype, both groups now have a guaranty that
nothing will go into that file which could break the content rules and
processing expectations of either group.

So that's how it would work the current
rules. I don't think that's the end of the world. Two groups that are conreffing
content probably need to have some level of coordination anyway - it's
not like map-based reuse, where you can just point at a topic; you're pointing
at an element ID, and hoping it's still there tomorrow.

Michael Priestley, Senior Technical
Staff Member (STSM)
Lead IBM DITA Architect 
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25

From:	"Rob Hanna" <rob@ascan.ca>
To:	"'ekimber'" <ekimber@reallysi.com>, "'Ogden, Jeff'" <jogden@ptc.com>, "'dita'" <dita@lists.oasis-open.org>
Date:	09/24/2009 04:16 PM
Subject:	RE: [dita] Why There are Constraints on Conref

---

Constraints potentially offer a unique opportunity
for managing different
business rules across an enterprise or industry. In my opinion, a task
is a
task - the current proposal seems to change that. Again in my opinion,
this
is fundamental to exchange of information across groups. What we are
otherwise talking about goes well beyond the simple task example provided
in
DITA 1.2. Architects could very well try to take advantage of the constraint
mechanism as a means of improving the usability of the authoring templates.
In so doing, under the current proposal, they would be rendering their
content unusable outside of their environment.

If one group imposes business rules that are stricter than another, that
group must decide how it wants to reuse content from the other group.
Ideally, the two groups can reach a mutual understanding and twin their
DTDs
to match. In reality, the business rules may be different for reasons beyond
the control of one group or another.

The worst possible result would be that the first group must rewrite and
manage the content provided by the second group because it was incompatible.
There are inevitably situations where this will occur - but we have an
opportunity to minimize the frequency of these situations.

The opportunities for reuse between constrained and unconstrained content
is
significant. Unlike examples cited where reference content is reused in
task
content, the two variations of constrained and unconstrained information
are
semantically similar. The failure or fall back mode of processors to handle
unconstrained content reuse within constrained topics should not be the
same
as reusing dissimilar content types.

I believe that authors and publishers should be alerted to instances where
the reused content fails to adhere to the stricter version of the model
but
they should not be prevented from using it.

What if we introduced a sort of name space mechanism to the conref that
could be used by processors to validate the content against the proper
model? This would only work between two topics of the same document type
(one loose and the other strict).

Cheers,

Rob Hanna


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php