In other words, we risk incompatibility with existing
implementations (if we specify) or future implementations (if we don't
specify). What do we know about existing implementations of conditional
processing? I only know of two uses of the otherprops attribute. The
first is by a customer that simply needed an extra attribute for
something other than conditionality, but their model is already not
DITA-compliant in other ways, so I would not worry about remaining
compatible with that instance. The second is by France Baril of
Ixiasoft, who described Ixiasoft's implementation in the dita-users
list:
I read the 's' at the end of otherprops and
figure it was probably there for something...
Basically, my suggestion is that you use
otherprops to include conditions for which there are no attributes. For
example, you could try something like this:
otherprops="condition1:valuecond1
condition2:valuecond2 condition3:valuecond3"
It is a little harder to process, but it works
with the current DITA implementation.
France's implementation is the only instance conditional processing
using otherprops that I am aware of in the wild. I personally like this
approach in that it allows for unlimited extension of existing
key:value attributes for conditional processing without adding new
attributes. If this is the only use of otherprops for conditional
processing out there, and if we adopt this in the spec, then there will
be no compatibility issues with existing implementations. I can see
some difficulty on the UI side in terms of making this author-friendly,
but it's doable.
Does anyone else know what other people do with otherprops?
Another thing I'm wondering: we require spaces surrounding individual
items in the class and domains attribute, but that is not a requirement
for the selection attributes. For those, they are merely
space-delimited. I would think that the ease-of-parsing reasoning would
apply to both. What's the reasoning behind this difference?
Chris
Michael Priestley wrote:
In the conditional
processing section,
it says:
"Each attribute takes zero or more space-delimited
string values."
Now, this is fine for semantically
grouped
values like those in the product or audience attributes, but is
inadequate
for otherprops, which might contain multiple semantic groupings. For
example,
otherprops might take parenthetical groupings of values as well as
directly
contained values.
Chris Wong pointed out that because
we haven't specified the syntax of otherprops in the past we could
invalidate
some existing designs by specifying it now.
We might be able to address this
concern
either by basing our design on the existing one if it passes muster, or
if there are multiple designs in use we could soften the wording from a
requirement to a recommendation in the case of otherprops.
Otherwise I think we leave a hole in
the specification that could result in multiple incompatible
implementations
of conditional processing code, and content that becomes tied to one
implementation
or the other.
Michael Priestley
mpriestl@ca.ibm.com
|