[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] weak/strong constraint proposal
I don’t understand why “Constraining a document
will affect copy/paste as well as conref”. It might, but not in the
same way or to the same extent. It
is true that copy/paste needs to be DTD valid by the time it is done, but so do
other forms of editing changes. What is validated is the actual markup to
be inserted. And implementations are free to make copy/paste as smart or
as dumb as they wish and can, but are not required to, transform the material
being pasted as necessary in an attempt to make it valid. Conref
validation is different. It isn’t DTD validation and uses information
from the domains and possibly the class attribute to validate potential rather
than actual markup. So
copy and paste from a general task to a strict task could work depending on
what markup is being moved, while conrefing the same markup from a general task
into a strict task won’t work (at least not for “strong”
conref validation). But the same could be said for copy and paste and
conref between different topic document types that use different domains and which
do not use constraints.
-Jeff From: Su-Laine Yeo
[mailto:su-laine.yeo@justsystems.com] Thanks
Michael. I see the value in the proposal and I don’t have a specific
objection to it, however to start the discussion I’ll recap a couple of
things I’ve mentioned in off-list discussions and in a previous TC
meeting: 1)
Constraining
a document will affect copy/paste as well as conref. If you constrain out
<lq> elements, for example, you won’t be able to paste anything
that contains a <lq> element and have it be valid. Depending on your
authoring tool, it could mean not being able to paste that content at all
unless you remove the <lq> element first. If
an organization’s goal is to simplify the user experience for authors (by
presenting a smaller element list), but they don’t want to strictly
disallow any structures, using constraints will be a problematic way to achieve
their goal regardless of whether we adopt this proposal. 2)
There are features on the DITA 1.3 list that I think are higher-priority than
this proposal. I’m
open to being persuaded otherwise, but for now I think that we should focus on
what is already in 1.2. Happy
Thanksgiving to the Canadians, by the way! I’ll be out of the office on
Monday Oct 12. Best
regards, Su-Laine Su-Laine Yeo JustSystems Canada, Inc. From: Michael Priestley
[mailto:mpriestl@ca.ibm.com]
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]