MHonArc v2.5.0b2 -->
dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [dita] conditional processing - inheritance case
I am aware that there are some concerns about how to process this in the
generalized form. Michael asked me to take a look, and I think I do have
one idea to make it easier.
Using the favorite props -> platform -> opsys example, the current routine
describes this:
domains attribute on topic is (props platform opsys)
original form: <p platform="intel" opsys="linux">
generalized 1 level: <p platform="intel opsys(linux)">
generalized 2 levels: <p props="platform(intel opsys(linux))">
There is justified concern about how to evaluate values like this last one,
with lots of nested parens.
My thought is - the domains attribute will always be present. [If it is
not, then you should have flattened out the attribute values to
platform="intel linux" because you no longer know how to get back to
opsys]. This means we know that opsys comes from platform - so why nest it
within the attribute? After all, it continues to represent a distinct
attribute value (if everything in this value is set to exclude, then
exclude). So, my proposal would be:
original form: <p platform="intel" opsys="linux">
generalized 1 level: <p platform="intel opsys(linux)">
generalized 2 levels: <p props="platform(intel) opsys(linux)">
When you re-specialize, you must tell your specialization routine what
level to target (true with or without this new proposal). When you want
generalize to opsys, you first check the domains attribute: (props
platform opsys). So, you know 2 things. First, opsys values may be located
in either the props or the platform attributes. Second, you know that you
can make both the platform and opsys attributes explicit, and that any
further specializations should be moved up into these attributes. So, take
this more complex case:
domains="(props platform opsys linuxflavor)"
<p props="platform(intel) opsys(linux) linuxflavor(redhat)">
When you re-specialize to opsys, you know that platform is valid, opsys is
valid, and opsys should contain any specializations of opsys:
<p platform="intel" opsys="linux linuxflavor(redhat)">
This has costs and benefits. The costs are primarily to specialization and
generalization - the logic for determining what goes where is more
difficult. However, it is possible to figure out. The benefit is that
run-time evaluation is far simpler - it is very easy to see what represents
a single attribute, and there is no hassle of parsing open and close
parens. My own view is that I'd much rather have the simplicity and time
savings on run-time evaluation, given that this will be performed far more
often.
Any thoughts? This just popped into my head while I was shuddering in fear
at some nested-parenthesis samples, so it could have holes I have not
noticed yet. However, it seems logical enough - the inheritance is already
expressed in your domain value, so it is not technically necessary in the
attribute syntax.
Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit
(507) 253-8787, T/L 553-8787
Michael Priestley
<mpriestl@ca.ibm.
com> To
dita@lists.oasis-open.org
04/20/2006 05:15 cc
PM
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]