dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [dita] Thoughts on Issue #20
- From: Michael Priestley <mpriestl@ca.ibm.com>
- To: Michael Priestley <mpriestl@ca.ibm.com>
- Date: Tue, 11 Apr 2006 10:33:39 -0400
Belatedly realized that my reply ditched
the color in the quoted text, so it's no longer clear when it's me being
quoted vs. Paul. Adding in extra > for my quotes that Paul is responding
to:
Michael Priestley
IBM DITA Architect and Classification Schema PDT Lead
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25
Michael Priestley/Toronto/IBM@IBMCA
04/11/2006 10:29 AM
|
To
| "Paul Prescod"
<paul.prescod@blastradius.com>
|
cc
| dita@lists.oasis-open.org,
"Su-Laine Yeo" <su-laine.yeo@xmetal.com>
|
Subject
| RE: [dita] Thoughts on Issue
#20 |
|
"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
>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]