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] [Fwd: Re: DITA @otherprops]


Sorry - just checking, based on the reliance on imaginary cases I was seeing.

I'll be more assiduous about monitoring the list.

Michael Priestley wrote:

Re:
>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?


There maybe a misunderstanding here. I would guess about a third of the TC consists of real users or represent groups of real users. I'm in both categories myself.

We've also had relatively detailed discussions of conditional processing use cases on the dita-users list, which I follow closely (I recommend you do the same). The scoped attribute value proposal in particular came out of some of Deborah's use cases, but unfortunately was deemed out of scope for 1.1 since it hadn't been discussed in detail on the TC yet.

Michael Priestley
IBM DITA Architect and Classification Schema PDT Lead
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25



Dana Spradley <dana.spradley@oracle.com>

04/27/2006 02:43 PM

To
dita@lists.oasis-open.org
cc

Subject
[dita] [Fwd: Re: DITA @otherprops]







oops! forgot to paste in the cc to the group

-------- Original Message --------
Subject:
Re: DITA @otherprops
Date:
Thu, 27 Apr 2006 11:35:58 -0700
From:
Dana Spradley <dana.spradley@oracle.com>
Organization:
Oracle Corporation
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
References:
<9B457B1322AAAE46BD5E693C02842C1D098AD236@nj0117exch002u.wh.lucent.com>



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]