I apologize, I'll try to stop being so cheeky about
the virtues of specialization in future.
It's just that it seems we're overengineering something that should be
much simpler - a prime buisness value - for the sake of semantic rigor
and imagined use cases - which seem of more dubious value.
What is that value of making webusertype a sub-species of audience -
instead of preserving it as audience since the values are the same?
Typically they
don't want to store the guest/registered etc. info in the base audience
attribute since it becomes confusing for authors
They also add a
specialization for webusertype, since otherwise
the distinction between audience and jobrole is not intuitive or
semantic.
Why not just rename the base audience attribute to
"webusertype" for internal business unit use, and transform it to
"audience" before generalization?
This is in fact what the DITA architectural spec recommends for people
who simply want to change the names of elements and attributes:
While specialization can be used to
adapt document types for many different authoring purposes, there are
some authoring requirements that cannot be met through specialization -
particularly splitting or renaming attributes, and simple renaming of
elements. In these cases, where the new document type can be
straightforwardly and reliably transformed to a standard document type,
the authoring group may be best served by a customized document type
that is transformed to a standard document type as part of the
publishing pipeline.
So it's okay to use specialization simply to rename
an attribute in this case - but not in others?
And since we're on that subject - why isn't it okay to use zero-degree
specializations that merely rename elements?
--Dana
Michael Priestley wrote:
In the use case, the business units
do add specializations for those other attributes, and one of them is
shown
in the example. They also add a specialization for webusertype, since
otherwise
the distinction between audience and jobrole is not intuitive or
semantic.
One of the basic promises of
specialization
is to allow different business units within a company, or different
companies
within a consortium, to share behaviors and processing at the level
that
makes sense: so for example, you could have a core set of
specializations
shared across the company that ensure a base level of consistency, and
then allow business units to further specialize from that base. Because
of the extension-by-restriction nature of DITA specialization, the
business
units are not breaking consistency by specializing: they are adding an
additional level of consistency, in the same way a business-unit-level
style guide could be more specific than a company-wide style guide, but
wouldn't contradict the company-wide style guide.
Another example might be a company
that
has solutions in various industries, and wants to conform to
industry-standard
specializations in those areas, while still serving up content through
a common company portal. For example, if a company has units that do
both
hardware and software, or programmer solutions and end-user solutions,
there may be different specializations that are appropriate for those
different
industries and audiences.
I hope it's clear that this has
nothing
to do with political failures. In my personal opinion it would be a
political
failure to force every part of a large company to use a single DTD with
no extensibility for specific industries or domains.
Michael Priestley
IBM DITA Architect and Classification Schema PDT Lead
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25
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
|