dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: conditional processing - inheritance case
- From: Michael Priestley <mpriestl@ca.ibm.com>
- To: dita@lists.oasis-open.org
- Date: Thu, 20 Apr 2006 18:15:04 -0400
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]