|
It
would be easy for me to change my usage of otherprops so that it allows for
multiple values for each condition. I.e. otherprops="
condition1:valuecond1 condition2:valuecond2 condition3:valuecond3 " could easily become otherprops="c ondition1:( value1cond1 value2cond1
) condition2:( value1cond2 value2cond2 ) condition3:( valuecond3 )
", or anything else for that matter.
Don't
mind my implementation, a quick search and replace will do the trick for
me, when time comes. And I only have one template to modify.
I'm
also open to completely different suggestions.
France
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
|