RE: DITA @otherprops

["Esrig, Bruce (Bruce)" <esrig@lucent.com>]

In the interest of full disclosure, if we go with the specialization approach without scoped values, and if you immediately need to encode a taxonomy, one systematic approach would be to put indicator variables into attributes and use the attribute specialization hierarchy as a surrogate for the value scoping hierarchy.

 

So (drawing an example from the general moldflow.com web site) rather than a single attribute:

 

product="Products/DesignAnalysis/MPI"

with value setting and matching against various levels of that hierarchy

 

You would have multiple attributes:

 

products="yes"

productsDesignAnalysis="yes"

productsDesignAnalysisMPI="yes"

with value setting and matching against whatever attribute was applicable to the intended scope

 

Bruce

-----Original Message-----
From: Deborah_Pickett@moldflow.com [mailto:Deborah_Pickett@moldflow.com]
Sent: Thursday, April 27, 2006 8:43 PM
To: Dana Spradley
Cc: cwong@idiominc.com; Esrig, Bruce (Bruce); mpriestl@ca.ibm.com; robander@us.ibm.com
Subject: Re: DITA @otherprops

By all means, do quote me if you need.

Something I didn't say in my first message - perhaps I implied it, badly - is that we have quite a hierarchical series of products.  You could easily draw a taxonomy of them all, and we would like conditional processing at any level ("This paragraph is for CAD products, all of them.").  We also tend to introduce new products whenever Marketing thinks it's a good idea, so whatever we do has to be extensible to be future-proofed.  Our requirements aren't as complicated as Hedley's (he and I have talked about that in the past), which you have already noticed.

We don't do much generalization/respecialization of content at Moldflow - not yet, but that may change with localization - so a lot of the discussion that's been going on lately with the TC about attribute extensibility isn't directly relevant to us.  But in terms of painting bike sheds, I should go on record as saying that I currently prefer IBM's colour.

--
Deborah Pickett
Deborah_Pickett@moldflow.com

Dana Spradley <dana.spradley@oracle.com>

2006-04-28 04.35

To	"Esrig, Bruce (Bruce)" <esrig@lucent.com>
cc	"'Deborah_Pickett@moldflow.com'" <Deborah_Pickett@moldflow.com>, robander@us.ibm.com, mpriestl@ca.ibm.com, cwong@idiominc.com
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