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
[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
|