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

[Joe Pairman <joepairman@gmail.com>]

Thanks for the thoughts, Jeremy and Michael. I think the most important thing is to not risk breaking people's existing content. If the blocking document-level compatibility check were added to all tools right now, that *would* break things for many people who use constraints. Either doing it as a warning only or adding separate markup for those who want document-level compatibility checks would avoid this (and I can't agree that "conref" should be the strict one in in the latter case, as it's currently used in a loose way by many groups).

However, I do wonder how many people would use separate strict markup if it were defined, as it seems that no-one is practicing document-level compatibility checks at the moment. And when would such checks be performed? If when creating content, the referenced document type could easily be modified after the fact. If when publishing, that's a bit late to be truly helpful.

Finally, it's still felt to be useful to define this kind of check in the spec, is it really so impractical to check the content model of the referenced element? Certainly when authoring, referenced elements are generally added one by one, so that would seem to allow time for checking, especially considering all the other actions that editing tools normally do for referenced content.

Just my impressions, and I do realize that I'm coming in at the tail end of a very long discussion, so may not have the full picture!

Thanks,

Joe

On Tue, Dec 17, 2013 at 6:27 AM, Jeremy H. Griffith <jeremy@omsys.com> wrote:

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/

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