Many
interesting issues are being raised, and I just want to address one of the memes
before it spreads:
“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.”
As
I understand the spec, architects who add constraints do not have to worry
about making their content unusable to others. You can conref more-constrained
content into less-constrained document types.
Su-Laine
Su-Laine Yeo
Interaction Design Specialist
JustSystems Canada, Inc.
Office: 778-327-6356
syeo@justsystems.com
www.justsystems.com
From: Michael Priestley
[mailto:mpriestl@ca.ibm.com]
Sent: Thursday, September 24, 2009 2:54 PM
To: rob@ascan.ca
Cc: 'dita'; 'ekimber'; 'Ogden, Jeff'
Subject: RE: [dita] Why There are Constraints on Conref
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