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: "Paul Prescod" <paul.prescod@xmetal.com>
- Date: Fri, 21 Apr 2006 23:35:08 -0400
Re:
>>OK it's a print-on-demand service
that constructs manuals based on audience type. The ditaval file is assembled
based on the profile information,
>>and the common content is processed
according to the ditaval file.
>
>If you don't have the document
or DTD yet then on what basis are you generating the ditaval? I thought
that the point of the scenario is that you're
>dealing with documents generalized
from unpredictable DTDs. It seems to me that, you're really making the
case for some kind of fall through behaviour.
No, the point of the scenario was to
show fallthrough behavior with ungeneralized documents still in their specialized
forms. That's what I was asked for, to demonstrate some potential usage
of multi-level specialization, and resist the amendment that would limit
specialization to only one level. The two scenarios I posted previously
dealt with generalization, this one did not.
In the scenario I posted the documents
do exist, in the form of topics and maps of various types and at various
levels of specialization. The only generated part would be the ditaval
itself, to reflect the profile of the current user. Perhaps I should repost
it adding more detail for each step.
Re your proposal below:
You identify two cases: attribute value
specialization (which the existing proposal had attempted to deal with
using scoped values) and attribute type specialization (which is what the
existing proposal stil deals with).
For attribute value specialization:
- where does the match from ""javaprogrammer"
to "programmer" get declared? How is it managed? How does it
get pulled in during generalization? How do we map values when there is
no formal enumeration?
For attribute type specialization:
- I don't see any examples. Is it the
same behavior as in the current proposal, or does it differ, if so how?
For specialization on a per-element
basis (like for note and for fragref):
- The current proposal had dealt only
with extending universal attributes, not ones that are element-specific.
For universal attributes, we can track inheritance using the domains attribute
of the topic element. How will you track attribute inheritance on a per-element
basis? Are you proposing adding a domains attribute to every element? This
is well beyond the scope of the current feature, which was deliberately
limited to universal attributes to avoid these issues.
I'd be happy to get value specialization
in whatever form (whether scoped attributes or your proposal below), but
I think the details of your proposal are a bit fuzzy for me, and I'm concerned
that we're leaving unanswered the questions that were open at the end of
Thursday's call re attribute type specialization, which we had already
agreed was the priority for 1.1.
Michael Priestley
IBM DITA Architect and Classification Schema PDT Lead
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25
"Paul Prescod"
<paul.prescod@xmetal.com>
04/21/2006 09:20 PM
|
To
| Michael Priestley/Toronto/IBM@IBMCA
|
cc
| <dita@lists.oasis-open.org>
|
Subject
| RE: [dita] conditional processing
- inheritance case |
|
From: Michael Priestley [mailto:mpriestl@ca.ibm.com]
Sent: Friday, April 21, 2006 9:58 AM
To: Paul Prescod
Cc: dita@lists.oasis-open.org
Subject: RE: [dita] conditional processing - inheritance case
OK it's a print-on-demand service that constructs manuals based on audience
type. The ditaval file is assembled based on the profile information, and
the common content is processed according to the ditaval file.
If you don't have the document
or DTD yet then on what basis are you generating the ditaval? I thought
that the point of the scenario is that you're dealing with documents generalized
from unpredictable DTDs. It seems to me that, you're really making the
case for some kind of fall through behaviour.
Looking forward to your proposal in
any case (especially if it supports multi-level specialization),
Okay, here it is: just as every
specialized element ties back to a generalized one, and every specialized
attribute ties back to a generalized attribute, every specialized attribute
VALUE would tie back to a generalized attribute value. I can see two basic
use cases.
#1. Your specialization wants
to deal with a subset of the values that the superset defines. (Like a
specialized element that simplifies its parent's content model)
#2. Your specialization wants
to deal with subtypes of the values that the superset defines. (Like a
specialized element that embeds specialized sub-elemenets)
I'll presume some magic fixed
attribute syntax for declaring these two situations. Let me give an example
of what happens during generalization.
Declarations:
"javaprogrammer"
value of the "programmers" attribute
specializes "programmer" value of the "audience"
attribute
"cplusplusprogrammer"
value of the "programmers" attribute
specializes
"plusprogrammer" value of the "audience" attribute
"enduser"
value of the "users" attribute
specializes "enduser" value of the "audience"
attribute
"administrator"
value of the "users" attribute
specializes "administrator" value of the "audience"
attribute
Specialized syntax:
programmers="javaprogrammer
cplusplusprogrammer" users="enduser administrator"
Generalized syntax:
audience="programmers(
javaprogrammer=programmer cplusplusprogrammer=programmer ) users( enduser
administrator ) "
Generalized interpretation:
audience="programmer
enduser administrator"
This helps for all sorts of enumerated
values:
Consider the "type"
attribute of note. It might be useful to specialize the "important"
value to "crucial" or the "other" attribute to "warning".
In fact, my proposal can be reverse engineered to handle "othertype".
It could also be used in "fragref"
to specialize "importance".
Paul Prescod
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]