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


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

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

Subject: Profiling atribute for customer

Profiling is a great thing and we always try to make use of it, wherever 
it makes sense.

We use use
* "condition" for specifying target output (manual, help, tutorial, 
* "conformance" for feature set (full, light, interdependencies of 
application modules)
* but then, we are missing something like "customer" (after all "vendor" 
is available), because our (standard) application has several customer 
specific extensions in function set and GUI and mixing these things up 
with the first two attributes will confuse our writers even more.

I admit, that normally customer profiling could be done with 
"condition/conformance", but as you can see, they are already used with 
a clear goal. I think that customer specific extensions are not that 
rare in our area, and the more or less "generic" profiling attributes 
like condition and conformance can be used for any purpose. Of course, 
instead of using condition for specifying target output, one could claim 
for a general "target-output" profiling attribute, making "condition" 
free for customer profiling. And we can surely find a lot of other 
further practices, all of them representable with their own profiling 
attribute :-/

I wait for some people to post that extensions to the schema of DocBook 
are very easy to realize in Version 5, but we cannot yet switch to it. 
And I'm not willing to use "role".

Are "customer" specific features in applications not a prevalent issue, 
in order to justify a new profiling attribute?

Thanks for any comment,

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