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: Dana Spradley <dana.spradley@oracle.com>
- Date: Fri, 21 Apr 2006 15:14:17 -0400
The DITA Architectural spec provides
a workaround for the fact that we don't support specialization, and in
that context (I think the section is called something like "limits
of specialization") it recommends ways to break the spec as painlessly
as possible. The point of this feature is to provide that support, lift
the limitation, and so lift the requirement for people to break the spec
by using the workaround.
Everything you're saying would equally
to element specialization, wouldn't it? You can call an element anything
you want and transform it when you publish. But then it's not specialization.
So: I think you're right in your analysis
of alternate approaches. But I also think that we have seen users find
value in what specialization provides elsewhere, and we have arguments
to add attribute specialization both from parallelism (we have an extension
mechanism for elements that people find useful, perhaps it will be useful
for attributes) and from use case (admittedly imaginary, but then it has
to be, since we can't have a real use case before we have the capability).
Michael Priestley
IBM DITA Architect and Classification Schema PDT Lead
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25
Dana Spradley <dana.spradley@oracle.com>
04/21/2006 01:44 PM
|
To
| Michael Priestley/Toronto/IBM@IBMCA
|
cc
| dita@lists.oasis-open.org,
Paul Prescod <paul.prescod@xmetal.com>
|
Subject
| Re: [dita] conditional processing
- inheritance case |
|
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
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]