dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [dita] conditional processing - inheritance case
- From: Michael Priestley <mpriestl@ca.ibm.com>
- To: "Paul Prescod" <paul.prescod@xmetal.com>
- Date: Thu, 20 Apr 2006 19:07:55 -0400
If "webusertype" directly
specialized props, then the audience logic for the corporate website would
not recognize it as a kind of audience, and would ignore the values in
it. Effectively, the corporate web site logic would have to be modified
when a business unit or product specialized one of the attributes it uses,
instead of automatically recognizing the specialized attribute as one it
supports.
This is reasonably parallel to what
would happen if, say, there was a company-wide behavior for a phrase tag
eg <productname>, that was specialized by some parts of the company
to be more specific, eg <serverpackage> vs. <softwarepackage>.
Without specialization, every new tag needs new behavior; with specialization,
fall-through processing can be applied where it exists/is appropriate.
Michael Priestley
IBM DITA Architect and Classification Schema PDT Lead
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25
"Paul Prescod"
<paul.prescod@xmetal.com>
04/20/2006 06:47 PM
|
To
| Michael Priestley/Toronto/IBM@IBMCA,
<dita@lists.oasis-open.org>
|
cc
|
|
Subject
| RE: [dita] conditional processing
- inheritance case |
|
I appreciate your effort in working
this through. I don't totally understand, however. Could you please outline
what in this scenario would work differently if the "webusertype"
and "jobrole" attributes directly specialized "props"?
From: Michael Priestley [mailto:mpriestl@ca.ibm.com]
Sent: Thursday, April 20, 2006 3:15 PM
To: dita@lists.oasis-open.org
Subject: [dita] conditional processing - inheritance case
Per a discussion today with Paul Prescod, Erik Hennum, Bruce Esrig, and
Eliot Kimber, here's my attempt at describing a scenario which involves
more than one level of specialization and takes advantage of inherited
processing (ie in which the semantic relationship to the ancestor elements
matter). The scenario is entirely made up and not intended to be descriptive
of any real company processes, but hopefully still plausible enough to
develop an understanding of how the type hierarchy might be useful in the
audience case.
- a company website has content delivered from various business units within
it
- all content is processed according to audience, and some content is hidden,
revealed, or flagged according to:
- guest user
- registered user
- business partner
- supplier
- customer
- company employee
- contractor working for the company
- for a lot of the content, this is enough, but some business units have
chosen to specialize audience to provide additional kinds of personalization
based on job role (manager, programmer, administrator, etc.); experience
level (expert user, novice user, etc.;); or educational background (highschool;
college/university; masters/phd, etc.); or other purpose. Typically they
don't want to store the guest/registered etc. info in the base audience
attribute since it becomes confusing for authors. So instead these business
units specialize audience to provide a "webusertype" attribute.
- when displaying content, the company website checks the content attributes
against the current user:
- if the "audience" attribute evaluates to exclude, the
content is excluded
- if any specializations of audience evaluate to exclude, the content
is excluded.
For example:
- current user is a registered guest, a business partner, and a supplier
- so we exclude content targetting guests (like invitations to register),
customers (like special promotions), or employees
So the following paragraphs are excluded:
<p audience="guest customer">This applies to guest users
or to customers</p>
<p webusertype="employee contractor" jobrole="consultant">This
applies to employees or contractors who are consultants</p>
The logic would be, as discussed in the phone call, that:
- a ditaval action can target a particular attribute, or an attribute and
its children
- when targetting an attribute and its children, the distinction between
attributes is still preserved - only one of the child attributes needs
to evaluate to exclude for the whole element to be excluded, like webusertype
in the example above
Hoping this scenario makes sense. The previous two scenarios I posted for
preservation of values during generalization to a particular DTD level
could also provide some justification for multi-level specialization. For
example, the specialization-unaware tool in the other scenarios might still
be aware of the first three levels of specializations in a company (on
a per-DTD basis), and only require generalization for specializations that
go beyond three levels. In that case, you would not want to generalize
all the way to the top and lose attributes unnecessarily - you would want
to preserve the attributes you can for whichever specializations the tool
supports, and only generalize when the DTD/Schema is unknown to the tool.
Michael Priestley
IBM DITA Architect and Classification Schema PDT Lead
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]