[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dita-comment] Remove or change emphasis of spec section on constraint compatibility?
On Mon, 16 Dec 2013 11:39:29 -0500, Michael Priestley
> <mpriestl@ca.ibm.com> wrote:
I understand your concern for future-proofing the conrefs.
> On Mon, 16 Dec 2013 08:36:49 -0500, "Jeremy H. Griffith"
>> <jeremy@omsys.com> wrote:
>>I think the spec should state the real restriction, that the
>>result must be valid DITA, and not impose arbitrary and often
>>onerous requirements intended to enforce that result. It
>>should be the responsibility of the author, not a rule for
>>the processor.
>
>The reason we didn't do this - with domains as well - was because there's
>a very real difference between "this reuse is valid at the time it was
>created" and "this reuse will remain valid throughout a working
>authoring/editing lifecycle unless you change doctypes".
>
>By validating that the document types provide equivalent constraints and
>markup capabilities, you can protect yourself against last-minute edits
>that break your publishing pipeline.
But future-proofing avoids a potential future cost by
imposing a real current cost. So we always have to weigh
the two costs, and the likelihood of the future risk, to
make a reasoned choice.
Yes, just not validate. That is probably true a lot of
>If your publishing pipeline can't be broken by the kinds of inclusion
>you're doing (in other words, it can tolerate unconstrained content or
>markup from unincluded domains), then it makes sense to turn that
>validation off.
the time. People use conrefs for variables, for example,
where there will only ever be text and perhaps typographic
elements like <b>. Using any restrictions in that case is
a waste of authoring time.
And in that case, which in my experience is pretty rare,
>But if your processing chain depends on tight/specific markup, and will be
>broken by incoming markup that is looser/unexpected, then validating
>compatibility of the document types is much stronger and more reliable
>than validating compatibility of the specific content at a single point in
>time (the time the reuse relationship is created).
you would want to validate. But having a processor enforce
this across the board, as the 1.2 spec advises, is pretty
Draconian.
I'd consider that rule way too expensive. I think you
>There are other ways to accomplish the same kind of strong validation -
>for example, I can imagine setting up a testing rule that says every time
>you change a reused element, you must revalidate every reusing document -
>but the current DITA approach works with distributed systems and with no
>dependency on special technologies or even a CMS.
hit on the right idea above; the user should be able to
decide case by case what level and sort of validation
is needed.
Yes, at a minimum. Perhaps even different attributes
>Again, I'm in favour of making "loose" conref the default, and documenting
>that clearly in DITA 1.3,
for loose and strict conrefs. Use "conref" for strict,
"textref" for loose, emphasizing that the loose form is
mainly intended for inclusion of text, not structure.
But don't *enforce* that constraint on the loose form;
give the authors credit for good judgement.
As I often say, one size does not fit all. Too often,
>But changing to a model that only ever checks content validity (ie that
>content is ok to reuse right here), and never checks context validity (ie
>that markup relationship is always ok to reuse, no matter what changes in
>its content) would sacrifice something of real value: the ability to make
>valid reuse relationships that aren't vulnerable to changes in the reused
>content.
the spec imposes requirements on everyone that are only
beneficial for a few, on the grounds that it is all or
nothing. I think our choices are broader than that,
and our tools should support that breadth.
-- Jeremy H. Griffith <jeremy@omsys.com>
DITA2Go site: http://www.dita2go.com/
--
This publicly archived list offers a means to provide input to the
OASIS Darwin Information Typing Architecture (DITA) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: dita-comment-subscribe@lists.oasis-open.org
Unsubscribe: dita-comment-unsubscribe@lists.oasis-open.org
List help: dita-comment-help@lists.oasis-open.org
List archive: http://lists.oasis-open.org/archives/dita-comment/
Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Committee: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=dita
Join OASIS: http://www.oasis-open.org/join/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]