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


I think Deborah already gave us permission in the body of the email, Bruce.

Thanks for the real-world use case, Deborah.

But for me it begs a question: have we been solliciting and collecting real-world use cases from DITA adopters, to make sure the way we're designing this new feature really does meet their needs?

Or are we just architecting in the dark here?

--Dana

Esrig, Bruce (Bruce) wrote:
That's really helpful, Deborah,
 
With your permission, one of us would be happy to quote you on the list.
 
Bruce
-----Original Message-----
From: Deborah_Pickett@moldflow.com [mailto:Deborah_Pickett@moldflow.com]
Sent: Wednesday, April 26, 2006 9:05 PM
To: robander@us.ibm.com; mpriestl@ca.ibm.com; cwong@idiominc.com; dana.spradley@oracle.com; esrig@lucent.com
Subject: DITA @otherprops


[Hi, I'm Deborah, and I'm a DITA user.  Some of you know me already.  I just wanted to speak up as a data point.]

I've been following the "attribute extensibility" discussion on the TC mailing list archive and I wanted to butt in on the use, or not, of @otherprops.  We at Moldflow don't use @otherprops primarily because of fear of commitment.  At least the way DITA-OT implements it, it is only a single axis of extensibility.  Example: our product-licence-management software requires several orthogonal axes: the product name, the operating system of the client, the operating system of the licence server.  In particular, the latter two can be independent, so it isn't appropriate to put them both onto one conditional attribute (where they would imply a union behaviour, and I want intersection behaviour).  There might be another down the track as we implement a second class of licence.  Having only one axis of extensibility in @otherprops doesn't give us any long-term benefit; in fact, it hinders us because it cements the use of @otherprops for that role and removes any leeway we might have [thought we had].  Also, to give @otherprops a specific purpose like this means that we have to document to authors why such a specific role has such a generic name.

Of course, there are workarounds, and we use them, but most of the content writers in my company are not technical and are having trouble understanding exactly what part of the workaround is workaround and what is architectural necessity.

Our group would, for the record, be quite happy to use a single attribute for all conditional logic provided that it and the processing model had explicit support for the conjunctive-normal-form* logic that matches our business and product model.

This message has sort of rambled off-topic, sorry.  But I wanted you all to know that yes, you do have customers that care about this stuff.

* no, that's not the right term.  I mean "conjunction of disjunctions" (prop1 = (a or b or c) and prop2 = (d or e) and ...), whatever set theory people call that.

--
Deborah Pickett
Deborah_Pickett@moldflow.com


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