OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [dita] otherprops syntax - should we specify?

Title: Message
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.
-----Original Message-----
From: Christopher Wong [mailto:cwong@idiominc.com]
Sent: January 10, 2005 4:32 PM
To: DITA TC list
Subject: Re: [dita] otherprops syntax - should we specify?

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?


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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]