[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: > 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/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]