Re: [dita] Thoughts on Issue #20

["Eliot Kimber" <ekimber@innodata-isogen.com>]

With respect to the proposal in issue 20 my opinions are:

For generic attributes:

- The core proposal is fine syntactically--I don't have a problem with 
the syntactic aspects. I don't see a better way to handle the 
generalization case syntactically.

- As for semantics, I don't think it is useful to try to define any 
semantic relationships between specialized conditional attributes and 
their values and the base DITA-defined conditional attributes and values.

That is, at the level of DITA-defined or DITA-expressible semantics for 
conditional attributes, specialized conditional attributes and their 
values are simply strings with no particular relationship to other 
conditional attributes or values that can be expressed or predicted 
based on DITA-defined mechanisms. For example, I don't think it's useful 
to consider that specialized attributes "hardware=" and "opsys=" are 
somehow specializations of "platform="--rather hardware= and opsys= are 
simply conditional attributes and any relationship between those 
attributes and platform= is not expressed or expressible using 
DITA-defined mechanisms. If the specializer's intent is that there are 
relationships, it's their job to document those or otherwise formally 
define them in whatever way they care to.

This keeps the mechanism as simple as possible, avoiding any tricky 
issues of semantics, which as the discussion on today's call shows, are 
complicated and fraught with difficulty.

Scoped values:

I like the scoped value proposal but I would certainly buy the argument 
that putting it in would put an undue burden on implementors unless we 
explicitly allow the fallback behavior of treating scoped values only as 
atomic strings, such that conforming processors do not have to support 
matching on subcomponents of scoped values.

For negative values:

I support negative values in general but the specification needs to 
clearly define what the precedence is in these cases:

cond="foo not foo"
cond="not foo foo"

The options are:

- positive takes precedence
- negative takes precedence
- first specified takes precedence
- last specified takes precedence

I vote for negative takes precedence--this allows you to build up values 
more or less blindly and still do selective negation.  For example, an 
application that sets conditionals might accumulate positive values from 
ancestors or from random outside sources and then at the end let the 
user negate something, leading to values like this:  cond="a b c not a" 
without the need to revisit the full set of values to eliminate 
now-redundant positive values.

I have no opinion about ditaval since that is implementation.

Cheers,

E.
-- 
W. Eliot Kimber
Professional Services
Innodata Isogen
9390 Research Blvd, #410
Austin, TX 78759
(512) 372-8841

ekimber@innodata-isogen.com
www.innodata-isogen.com