Re: [dita-comment] Remove or change emphasis of spec section on constraint compatibility?

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

Hi Jeremy,

One clarification and I think we're
mostly in agreement:

>And in that case, which in my experience is pretty
rare, 
>you would want to validate.  But having a processor enforce
>this across the board, as the 1.2 spec advises, is pretty 
>Draconian.

The 1.2 spec does NOT advise this. It
says processors "may" do so - that's not even a "should"
let alone a "must".

I'd like to clarify the wording further,
but we're already at the optional level.

Michael Priestley, Senior Technical Staff Member (STSM)
Total Information Experience (TIE) Technology Strategist
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25



From:      
 "Jeremy H. Griffith"
<jeremy@omsys.com>
To:      
 Michael Priestley/Toronto/IBM@IBMCA,

Cc:      
 dita-comment@lists.oasis-open.org,
Joe Pairman <joepairman@gmail.com>
Date:      
 12/16/2013 05:28 PM
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:

> 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.

I understand your concern for future-proofing the conrefs.
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.

>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.

Yes, just not validate.  That is probably true a lot of
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.

>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).

And in that case, which in my experience is pretty rare, 
you would want to validate.  But having a processor enforce
this across the board, as the 1.2 spec advises, is pretty 
Draconian.

>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.

I'd consider that rule way too expensive.  I think you
hit on the right idea above; the user should be able to 
decide case by case what level and sort of validation 
is needed.

>Again, I'm in favour of making "loose" conref the default,
and documenting 
>that clearly in DITA 1.3, 

Yes, at a minimum.  Perhaps even different attributes 
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.

>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.

As I often say, one size does not fit all.  Too often,
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/