RE: [dita] Thoughts on Issue #20

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

"Paul Prescod" <paul.prescod@blastradius.com>
wrote on 04/04/2006 01:12:51 PM:

> re 4: not sure I understand your grounds for objection fully, but
in
> any case the proposal does describe how to change the default 
> behavior for a particular ditaval file, but I'm reluctant to change
> the default for every ditaval file because, regardless of the merits
> of your argument, it would be backwards incompatible (ie every 
> document out there created based on existing default behavior would
> break with your change). Hence my desire to make the change an opt-
> in rather than global. 
> First: Can we have a more explicit syntax for
this? E.g. a <default>
> element with an occurrence pattern of singleton? 

The current proposal is as follows:

First, preserve 1.0 behavior:

<prop att="audience" val="programmer"
action="exclude/> -- acts according to 1.0 doc (if "programmer"
is the only value in the "audience" attribute of an element,
the element is excluded). 
<prop att="audience" val="programmer"
action="include/> -- acts according to 1.0 doc (effectively ignored,
since content is included by default anyway - used for convenience in tracking
lists of potential values in a ditaval file)

Your proposal would arguably break the above 1.0 behavior,
and hence backwards compatibility. (I say "arguably" because
the spec only talks about how to evaluate exclude behavior - because the
include action was a no-op, and not documented in the spec, it doesn't
have documented behavior, just existing behavior in the toolkit, which
ignores the value).

Second, allow defaults to change 1.0 behavior:

<prop att="product" action="exclude"/>
-- excludes any value in the "product" attribute, so any products
that aren't explicitly included are excluded by default.
<prop action="exclude"/> -- excludes
any value in any attribute

Neither of these options are exactly equivalent to
your proposed behavior, but I think they do provide an equivalent level
of control. I think the ability to define different defaults for different
attributes could be particularly useful: if you never build docs for more
than one product, but often for more than one platform, you can set "product"
default to exclude, and "platform" default to include, for example.

To get the behavior below, an author would need to
set two elements rather than one:
1. change the default for the attribute they want
to generally exclude
2. explicitly include the values in that attribute
they want included

I realize that's an extra step, but I think it's a
necessary extra step to:
- preserve backwards compatibility
- allow different behaviors on a per-attribute basis
  
> Second: I'm not convinced that setting the default
ends up with the 
> behaviour that I believe is intuitive and consistent. It isn't that
> I want the default to be "exclude". As in the document,
I want the 
> following behaviour:
>  
>  1. if an attribute is not mentioned at
all in the ditaval, then 
> ignore it (include elements that have it set, no matter what the value)
>  
>  2. if any attribute value is mentioned
positively in the ditaval 
> and in the document, then include the element
>  
>  3. Otherwise: the attribute has values
with a positive mention but 
> none of them match the element. Exclude it.
>  
> If I set the default to be "exclude"
then the first rule will be 
> violated. This becomes a problem when new conditionality attributes
> are added and old ditaval files are used. Your instinct of "include
> by default" is the best in that case.
>  
>  Paul Prescod
>