dita — archive

RE: [dita] attribute extensibility - summary

From: Don Day
To: [email protected]
Date: Thu, 27 Apr 2006 19:08:00 -0000

MHonArc v2.5.0b2 -->

dita message

Subject: RE: [dita] attribute extensibility - summary

From: Don Day <[email protected]>
To: [email protected]
Date: Thu, 27 Apr 2006 14:12:14 -0500

I am forwarding this message from Paul Prescod, for whom the OASIS mail
server is not working nicely at the moment.

(Paul, I'll alert Carol Geyer about your issues.)

Please excuse my pointy haired boss jargon but I'm having trouble
extracting "action items" from your text below. What are you
advocating
be done?


> ________________________________
>
>              From: Esrig, Bruce (Bruce) [mailto:[email protected]]=20
>              Sent: Thursday, April 27, 2006 2:57 AM
>              To: 'Dana Spradley'; Michael Priestley
>              Cc: [email protected]
>              Subject: RE: [dita] attribute extensibility - summary
> =09
> =09
>              I'll resort to general principles in a moment,
> but first let
> me
> argue from a particular case.

and thus on to the note below...

Regards,
--
Don Day
Chair, OASIS DITA Technical Committee
IBM Lead DITA Architect
Email: [email protected]
11501 Burnet Rd. MS9033E015, Austin TX 78758
Phone: +1 512-838-8550
T/L: 678-8550

"Where is the wisdom we have lost in knowledge?
 Where is the knowledge we have lost in information?"
   --T.S. Eliot


                                                                           
             "Esrig, Bruce                                                 
             (Bruce)"                                                      
             <[email protected]                                          To 
             >                         "'Dana Spradley'"                   
                                       <[email protected]>, Michael 
             04/27/2006 04:57          Priestley <[email protected]>     
             AM                                                         cc 
                                       [email protected]           
                                                                   Subject 
                                       RE: [dita] attribute extensibility  
                                       - summary                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




I'll resort to general principles in a moment, but first let me argue from
a particular case.

1. I keep trying to bias the argument so that we say that we need to be
able to support independent pools of values for newly-introduced
attributes. Alas, having written the next paragraph, I don't see a
necessity for splitting the value set. Each value is not tied to any
particular attribute until it is used as a value for that attribute. So it
is the attribute-value pair that has significance, and the semantics of
that pairing is what we should be trying to preserve.

Specifically, we should add to our user input the offline input of Deborah
Pickett of Moldflow, who asks for multiple "independent axes" of
conditionalization. In her example, the operating system of the client and
the operating system of the license server may be independent. Her example
may not be sufficient to require us to split the value pool, provided that
the mechanism we adopt is able to simultaneously specify two desired
matches: a value an attribute "os-client" and a match of a value in a
second attribute "os-license-server". The fear I had was that during
generalization, the separate attributes would collide, but ... (a) in the
XSLT discussion, we seem to be proposing a syntax that will collapse the
separate values into a single generalized attribute while retaining enough
information about their origin to distinguish them and (b) because the
separate attributes are being collapsed into a single attribute, there is
no risk of a collision of attributes in the generalized XML as a result of
using the two specialized attributes simultaneously.

2. Returning to the general principles, Erik Hennum has now published a
more extensive explanation that takes an integrated point of view of both
element and attribute specialization. This deserves a separate response.

3. Looking back at the discussion between Dana Spradley and Michael
Priestly, there seem to be a few main causes for the divergence in their
points of view.

3a. The most fundamental difference, in my view, is between a denotational
and an operational view of semantics. Michael's success criterion, in the
end, has been primarily operational. His court of last resort is the
evaluator of conditional attribute settings. If the evaluator can use the
data to do what we judge to be the right thing, then the language design is
adequate. Some of Dana's requests have been more denotational. How can we
tell that the set of language features that we are proposing is necessary
and sufficient? Do we have an agreed upon model consisting of objects
(elements and attributes) and their relationships (specialization of
various kinds) that allows us to interpret each expression means
(denotation), and do we agree on what the method of interpretation should
be?

These approaches have some junction points and common language. The
evaluator is an implementation of an interpretation. But the denotational
meaning of "interpretation" includes the entire mapping, whereas the
evaluator focuses primarily on making sure we know what to do with values
of attributes. The various notions of specialization also constitute common
language, since we can agree on what we mean by each of those notions.

Our closest approach so far to the development of a model theory for the
joint problem of specializing elements and attributes is in the line of
discussion that Erik Hennum provides. That discussion contains rules that
are derived from a more or less explicit model (need to check the Extreme
paper). In language design, model theory is somewhat of a gold standard. If
your language is based on a model, then you can be confident that there is
a single point of view from which all the constructs make sense. In our
discussions, we use the word model, but I don't think we have attempted to
construct one in the denotational sense. We may not need to, if we can
agree that our constructs are consistent, but if we can't agree, then to
progress, we may need to construct at least a substantial subset of the
model.

3b. Aside from this methodological challenge, we also have a procedural
one. We have an increasingly-detailed proposal for how to offer new
attributes using a specialization-like mechanism. We don't have the
equivalent for an alternative, so we cannot compare.

If we are concerned with making a correct decision, we may need to explore
"the road not taken" a little bit to see where it leads. That is what
Michael has been raising as the high-cost (in terms of architecture time)
alternative.

For example, suppose we had a syntax for declaring new attributes, but the
values of the new attributes were never lumped together into a single
generalized attribute. This would have the appealing effect of completely
separating the value spaces for the new attributes from one another and
from the existing value spaces. If the theory (in paragraphs 2 and 3 from
the top above) is correct, we don't need to achieve this separation. A
second appealing effect would be to reduce the overhead on the language
customizer of specializing attributes. This reduction may come anyway if
Erik Hennum's program is adopted. A third effect, a disadvantage, would be
that there wouldn't be a systematic approach that supports specialization
for those who want it.

Looking down this road just that far, I don't see a reason to pursue it.
This despite my expectation going in that it would be a productive road
that we should pursue.

4. We do have an early adopter effect that we should also acknowledge. We
have wished to make it the case that the DITA toolkit is not the
authoritative unique implementation of DITA. However, for those who are
pursuing independent implementations, the power of community development of
ideas, together with the rapid translation of those ideas into an
implementation in the DITA toolkit, makes it hard to maintain an
alternative.

Best wishes,

Bruce