Okay, now I get what you meant about consistency
Michael.
But isn't this use case a little backwards?
Wouldn't you leave the existing audience values alone, and add
specializations for job
role, experience
level, educational background, etc?
At least, that's what I'd do if I were specializing - so that the
existing logic could handle the existing values.
As for the new semantic subcategories...well, the existing logic would
have no notion of what to do about them, would it?
I also find something else odd about this use case - indeed, about all
similar round-tripping use cases: do that many companies really allow
individual business units to go off the reservation that way?
Wouldn't they instead require the units to negotiate a common
company-wide approach?
Or is this dedication to round-tripping a way of compensating for the
internal political failure of some large corporations to do as much?
--Dana
Michael Priestley wrote:
From my perspective, the intent was
always to allow multi-level specialization: props was introduced as an
ancestor of the other conditional processing attributes, to unify the
conditional
processing attribute hierarchy. But I wasn't clear on that in the
feature description, and there was discussion on whether it was
necessary.
I came up with the following use case to provide at least one scenario
in which the multi-level specialization would have actual processing
implications,
in addition to merely semantic ones.
Michael Priestley
IBM DITA Architect and Classification Schema PDT Lead
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25
I was lurking for some of the meeting -
but must have missed something germane to this discussion.
So you're thinking of extending specialization to all conditional
attributes
- not just props?
Michael Priestley wrote:
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
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
|