Okay, thanks for clarifying that Michael: you do
reject Chris's compromise - or maybe everyone at IBM does.
Then I guess we're at loggerheads - particularly because I see no need
to call this "specialization" in 1.1.
This first I can trace coming across this was in an Indi Liepa email of
4/5/05: "Same issue as that raised by others relating to how to extend
DITA attribute set."
And as I recall until very recently the proposal referred to
"extensible attributes."
And given the lack of real-world user demand for anything more, I see
no danger in adopting Chris's compromise solution in 1.1 - and much
more danger adding a notion of "attribute specialization" to the
architecture before we fully understand what we're getting ourselves
into.
--Dana
Michael Priestley wrote:
>So far nothing you have said has
contradicted
that. If it has, then maybe I haven't understood you. Let me know.
My issue with Chris's proposal is
that
I'm not convinced we can call something specialization if it is limited
to one level, has no inheritance structure, and no generalized
processing
support. And that if we allow this, and call it specialization, we will
be compromising the value of our general statements about
specialization.
Sorry if that wasn't clear.
In addition, Chris's proposal
depends
on the props attribute not being directly authorable, which makes me
concerned:
it would mean that a base topic without domains could not be
conditionally
processed, and I would regard conditional processing as something that
should be enabled even in the simplest case.
In terms of post-1.1 work, you
already
know what I consider to be essential aspects of specialization
(including
multiple levels of inheritance, generalization round-tripping,
comparability
of doctype differences eg for conref, and processability of the
generalized
form). If you want to call it marsupial inheritance, go ahead - the
point
is it works and is part of the current DITA value proposition, so I
would
hope that any proposal you come up with would respect those traits.
I'll defer to Erik to provide URLs
for
his speculative work on potential futures for DITA specialization, it
sounds
like you have a lot to talk about :-)
For 1.1, though, I'm hoping I've
made
my concerns clear with respect to the dangers of a too-limited
solution.
Speaking at least for IBM, we do see use cases for specializing more
than
one level, and see some value in being able to identify the semantic
relationship
between e.g. jobrole and audience, or operatingsystem and platform; and
I do have concerns about the impact on the architecture of not allowing
that expressiveness.
Michael Priestley
IBM DITA Architect and Classification Schema PDT Lead
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25
Yes, I do think I understand your
position,
Michael - I guess I just disagree with it, as you apparently disagree
with
mine.
But beyond these now hardened positions, I think I'm trying to propose
a compromise - or rather, second a compromise Chris Wong has proposed -
that would be a win-win for both of us: you could continue to think of
this as severely restricted attribute specialization, I could consider
it as severely limited element specialization, and users would get what
they wanted when they requested this enhancement - nothing more - in a
1.1 timeframe.
So far nothing you have said has contradicted that. If it has, then
maybe
I haven't understood you. Let me know.
As for adding new attributes to elements as a species of element
specialization,
I've been thinking about that a lot the last few days, and maybe I
should
share with you more of where I'm coming from architecturally - though
please
don't allow this to take the limited discussion of what to do right now
in 1.1 off track.
I've lately been thinking that we should consider adding new attributes
to elements without changing the element's name or invoking a
specialization
hierarchy as a kind of genetic mutation: highly adaptive in a
particular
environment, but alas - incapable of being inherited by the element's
specialized
children.
If you want to add attributes that will be inherited by the element's
progeny,
then you need to change the name and insert the element in its
specialization
ancestry the usual way.
The fallback behaviour of an element that has new attributes is the
behaviour
of that element before the attributes were added, in all cases. What
else
would it be?
On the other hand, since DITA parents are so solicitous of progeny that
they allow, like some strange kind of uber marsupial, all their
specialized
childred - even the mutants - to crawl back into the pouch for
protection
so they can undergo processing in a generalized form before being
respecialized
back out again - we provide at least one - maybe only one - universal
attribute
to preserve them inside the body of their parents.
That at least is the most rigorous way I can combine the metaphors that
structure DITA and XML and have them make sense.
--Dana
Michael Priestley wrote:
Our alternatives are:
- call it specialization, but change the meaning of specialization (ie
for extension of universal attributes, specialization will be one-level
only, and will require a virtual base attribute, and the base attribute
cannot be used on its own - no fallthrough, no inheritance, no
simultaneous
existence of child and ancestor elements)
- don't call it specialization, and change the meaning of DITA (ie have
a new extension mechanism, and recreate all of the specialization
infrastructure
around it).
- call it specialization, and enable multi-level inheritance and
generalized
value processing
I believe my stance has been completely consistent - targetting a
narrow
scope for 1.1 that meets the architectural definition of specialization
for the specific kind of attribute extension we know is highest
priority.
Identifying that narrow scope did require a lot of hard thinking, and
I'm
definitely feeling some pressure from you to discard that thinking,
which
I'm resisting because, as I've said repeatedly, I believe the
alternatives
are worse.
Do you understand my position? I feel like I'm repeating myself, and
that
probably means we're talking past each other.
Michael Priestley
IBM DITA Architect and Classification Schema PDT Lead
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25
But specialization of what...element or attributes?
If done as specialization of attributes, I disagree: it *does* have
major
architectural implications - not only in DITA, but in XML itself -
since
in the XML spec, as I've previously said, attributes are always
subordinate
to a particular element, and don't float free as things in their own
right.
And at least as I've been hearing the discussion, this enhancement has
been pitched lately as adding a new and unprecedented specialization
method
for attributes - requiring you, as you've several times admitted, to
think
long and hard about how that would make the most sense.
--Dana
Michael Priestley wrote:
1) I have never claimed this proposal is a general solution for
attribute
specialization. The title has changed over time to try to remove
ambiguity
("metadata attributes" was the original title, but that caused
some confusion) but the core requirement has always been extensibility
of conditional processing attributes.
2) It has no major architectural implications IF it is done as
specialization,
which at least in other contexts has always implied unlimited levels
and
generalized processability.
Michael Priestley
IBM DITA Architect and Classification Schema PDT Lead
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25
Fine. Then why try to claim this proposal amounts to a full-fledged
proposal
for something unprecedented in DITA - attribute specialization,
something
appropriate to be unveiled in a major release - when it's really just a
narrowly targeted fix to allow for additional universal attributes to
be
added to elements - in particular, conditional processing attributes -
that has no major architectural implications?
That's the kind of proposal that would be appropriate for a point
release
like this.
Now when our users requested this enhancement, did any of their
requests
include anything that couldn't be handled by the compromise scope Chris
Wong proposed? Was there anything in these requests that would require
the more extensive scope added in the last couple of weeks?
If not, then why are we engineering stuff into this feature that our
users
aren't even demanding yet?
Perhaps a better approach would be to limit the enhancement to Chris's
scope for now - but provide a "possible future direction" note
in the spec that would explain and preserve the expanded scope - and
ask
any users out there who need this further enhancement to contact us
before
the next point release so we can further consider it?
If no one contacts us, then we don't need to engineer this feature any
further.
And yes please, could you send me urls to Erik's presentations on
general
attribute specialization? I'm also interest in seeing the most elegant
solution possible adopted for the general case, without undue
complication.
--Dana
Michael Priestley wrote:
We actually did do exploratory work on full attribute specialization,
and
there have been some thought experiments undertaken by Erik Hennum on
what
a full solution might look like - I'll defer to Erik to provide URLs to
some of his presentations.
But the very minimum that would be required to allow per-element new
attributes
would be per-element tracking of new attributes, which would mean a new
universal attribute for tracking attribute ancestry - effectively,
adding
something like the domains attribute to every element. This would
affect
generalization, conref, and domain integration rules substantially, in
a way that the current much more limited proposal avoids.
Also, keep in mind that the number one requirement for the next release
of DITA is not the ability to add arbitrary new attributes on a
per-element
basis: it is the ability to define new conditional-processing
attributes.
So I think we are addressing requirements in the order prioritized for
us by our users, as well as in the order that requires the least
architectural
rework in a point-release of the standard.
Michael Priestley
IBM DITA Architect and Classification Schema PDT Lead
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25
True, Michael - but currently in DITA specialization is something that
applies to elements alone, not attributes.
And I guess what I'm really resisting is the attempt to use this
feature
to define a new kind of specialization for attributes alone, before we
really understand what we're doing.
As Paul has repeatedly pointed out, in XML attributes are properties of
elements - they have no independent existence of their own.
An attribute of the same name can, in XML, have a different datatype,
and
different optionality, even a different list of enumerated values,
depending
on the element with which it is defined.
The fact that we can use a parameter entity to define a collection of
universal
attributes and put that entity in the attlist of every element has, I
think,
started to blind us to the fundamental architectural dependence of
every
attribute on the element who attlist defines it.
Now I admit that we've gone too far down this road to get
specialization
of elements through new attributes by any other method than the one
we're
pursuing here in a 1.1 timeframe - and as such I'm happy to go along
with
the compromise scope Chris has proposed.
But if we had it to do over, I think we would have been better off to
enhance
element specialization by adding new per-element attributes first,
before
we defined enhanced element specilization by adding new universal
attributes, as we are attempting to do now - in my most charitable
construction
of the proposal.
--Dana
Michael Priestley wrote:
You're right, I'm shying at shadows. Chris is not proposing to ditch
specialization.
But he is proposing to limit specialization in ways that make me
question
whether it's still specialization:
- currently in DITA, specialization means any number of levels
- currently in DITA, generalization means creating a version of the
content that conforms to the ancestor type declarations while
preserving
the processable semantics of the descendant declarations
- if our conditional processing support doesn't meet these definitions,
can we still call it specialization?
We do have a design currently proposed that allows any number of
levels,
and describes how to process the attributes in their generalized form.
And I don't think the argument that it compromises WYSIWYGness is a
strong
one, given the edge-case status of someone directly editing generalized
content.
So I'm resisting increasing the scope, because I think we're already
stretched
to the limit in what we can cover in this feature for 1.1, but I'm also
resisting decreasing the scope, inasmuch as that compromises the
existing
published statements about specialization and generalization.
Michael Priestley
IBM DITA Architect and Classification Schema PDT Lead
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25
I don't follow Michael.
How does limiting the scope as Chris suggests amount to "ditiching
specialization?"
It still provides a mechanism for new conditional attributes through
the
props attribute.
--Dana
Michael Priestley wrote:
If we introduce a new extension mechanism that is not specialization,
we
will need to consider, among other questions:
- how are the extended values preserved during generalization? are they
even affected by generalization? if yes, isn't it specialization? if
no,
haven't we just broken our entire extensibility/interchange model?
- how is the use of these attributes signaled to processes that care
about
doctype differences, eg conref? or are they ignored? if ignored, how
can
we tell whether two topic types are truly content-model compatible? if
not ignored, do we add the info to the domains attribute? if yes, isn't
it specialization? if no, do we need another architectural attribute?
Specialization is designed to solve a whole range of processing
implications
to reconcile customized doctypes that need to be interchanged. If we
ditch
specialization for this case, those problems get bigger, not smaller.
If
we ditch both specialization and stop caring about the problems it
solves,
then we break most of the promises that have been made about DITA in
its
charter, spec, etc.
As it says in the proposal, this is for conditional processing
attributes
(which are universal), and for arbitrary tokenized universal
attributes.
Our requirement for 1.1, as ranked by both the TC and by public input,
is to provide a mechanism that allows new conditional attributes. We
allowed
in the arbitrary tokenized universal attributes as a "if we enable
it for conditional attributes, the same logic will apply to other
attributes
that have the same occurrence pattern and syntax, so it's free for that
case".
I am honestly trying to solve as small a problem as possible, without
breaking
DITA's basic architectural promises. That's why it's limited to only
two
cases, that's why we ditched the scope and negative value use cases,
that's
why I'm continuing to focus on attribute type specialization and not
attribute
value specialization, but I don't think making the problem so small
that
it excludes specialization is possible without the entire solution
becoming
something other than DITA.
Michael Priestley
IBM DITA Architect and Classification Schema PDT Lead
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25
I agree with Chris's take on the appropriate scope for 1.1.
While I admire Michael's desire to realize the larger promise of
specialization
in this feature immediately, I think that would be more appropriate in
a 1.2 or even 2.0 timeframe, when we've all had a chance to consider
the
implications fully.
We're already limiting general attibute extensibility to NAME values so
it can be accomodated by the simplified syntax originally proposed for
conditional attribute extensibility. Yet now we're busy complicating
the
conditional case considerably, raising the question of why a dedicated
syntax for the general case was judged out of scope originally.
Also the model proposed for full-fledged attribute specialization here
is appropriate only to conditional attributes. If we are going to
include
a coherent and consistent approach to specialization for attributes as
part of this proposal, it should apply to all kinds of attributes, not
just conditional processing ones.
--Dana
Chris Wong wrote:
I wouldn't be so quick to dismiss authoring requirements, Michael.
Authors
do like to see a reasonable preview of their conditional text. This
implies
reconciling @props and the specialized attributes and all the
complexity
in @props. Even if the authoring tool implements this, writers
themselves
will not be isolated from the complexity of trying to understand why
certain
text is hidden/shown. If the authoring tool only implements conditional
processing or profiling on the actual attributes, then you have the
divergence
between preview/authoring output and final output.
Chris
From: Michael Priestley [mailto:mpriestl@ca.ibm.com]
Sent: Tuesday, April 25, 2006 10:11 AM
To: Chris Wong
Cc: dita@lists.oasis-open.org
Subject: RE: [dita] attribute extensibility - summary
Chris, in a separate reply I've addd my own concerns about scope creep
for 1.1, but it does differ from yours. I do still think we need
conditional
processing logic that will match against the generalized form as well
as
the specialized form. I posted two scenarios to the list earlier that
described
cases where this could be necessary, and it is an existing promise of
specialization
that I am reluctant to break in the context of attribute
specialization,
for numerous reasons (eg it's actually useful functionality; it's
consistent
with other behaviors; it makes it difficult to talk about
specialization's
general capabilities if we have exceptions and caveats all over the
place).
In terms of the specific processing for props, Rob A's proposal has a
reasonably
clear discussion of the implications I believe, and I'm hoping you've
had
a chance to read it. His proposal reduces the generalization nesting to
just one level, which is sufficient to distinguish different
dimensions/axes
of attributes (which affect processing logic) without necessitating
recursion.
.If this is too complex for your applications, perhaps we could
distinguish
between required behaviors for different kinds of application:
- the generalized syntax is not intended to be directly authorable, and
need not be supported by authoring applications
- the generalized syntax is intended to be a way to resolve differences
between applications that share common processing pipelines, and so
processing
pipelines/final output processes should respect/interpret the
generalized
syntax
Would that help?
In specific response to your suggestion below that props be a virtual
attribute,
I do think there are cases where props will have values authored in it
directly (eg when a DITA specializer has only one set of conditions to
worry about), but I don't think that should complicate the logic beyond
hope. Here's what I believe the logic would be, for a
generalization-aware
conditional processing app (Robert, correct me if I'm wrong):
- processing app checks ditaval to get list of attributes and values to
check (eg audience, "programmer")
- processing app opens a document, and checks domain att to get list of
ancestors and children of the given attribute (eg props=ancestor of
audience,
jobrole=child of audience), and revises the list of attributes to be
checked
(eg props, audience, progammer)
- processing app checks each attribute for the values given (eg
"programmer")
- if an ancestor attribute has a subtree labelled with the given
attribute
(eg props="audience(programmer)") then evaluate that subtree
as if it were an attribute
- if the given attribute or any of its children have either directly
contained
values or subtree values that match the given one (eg "programmer"),
evaluate the attribute or attribute subtree in question.
This is complex, I agree, but I don't think beyond hope - and it only
needs
to happen for the pipeline case, and never affects authoring, and
provides
specialization-aware interoperability which is consistent with our
existing
behaviors and messages about DITA and specialization.
Michael Priestley
IBM DITA Architect and Classification Schema PDT Lead
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25
I was catching up on this discussion (thanks for this summary, Bruce)
and
as I waded through the emails I'm getting a sense of dread and panic.
Guys,
have you considered how scary and complex this is becoming? When you
start
to see something resembling LISP code in your attributes, maybe there
is
some overengineering going on.
The main motivation behind this feature is to simplify conditional
processing.
We already have a mechanism in DITA 1.0 to extend metadata axes by
stuffing
everything into @otherprops. Nobody uses it. People only want to work
with
attributes. Michael, you did distinguish between authoring complexity
and
processing complexity, but the two are not easily separable the moment
anything goes into @props. Conditional content can be expressed in both
@props and its specializations, meaning two attributes can be
complement
or conflict. Authors/editors/publishiners have to reconcile or debug
the specialization chain, even if they are working at a generalized
level.
What should specialized metadata axes mean in a generalized form? If I
am working with -- and understand -- only a generalization of some
specialization,
I would not know what to do with all those strange things in @props.
May I suggest the following to simplify common usage?
- @props shall be the
magic specialization
bucket. It is used only to facilitate specialization/generalization
transforms,
and shall be ignored otherwise.
- @props shall not at
any time
contain metadata of interest to the current level of
specialization/generalization.
Any relevant metadata shall be in specialized metadata attributes.
- Apart from @props,
metadata
attributes shall not contain complex expressions needing parenthesis.
- Conditional
processing -- whether
authoring or processing -- shall use only real metadata attributes and
ignore anything in the magic @props bucket.
Under
this scenario, it no longer matters how complex @props becomes. The
only
time we worry about its content is during specialization or
generalization,
where specialization-aware transforms should understand its complexity
anyway. The rest of us mere mortals who want to implement, author or
publish
DITA with conditional processing will only have to work with the actual
attributes. Existing tools for conditional processing -- even non-DITA
tools -- that work off the attributes will be right at home.
My apologies for jumping in like this. I have not had the time to
participate
in your discussions, and I have no intention of derailing your current
thread of discussion. But I hope you will consider the need to simplify
usage in the common case.
Chris
From: Esrig, Bruce (Bruce) [mailto:esrig@lucent.com]
Sent: Tuesday, April 25, 2006 8:44 AM
To: 'Michael Priestley'; Paul Prescod
Cc: dita@lists.oasis-open.org
Subject: RE: [dita] attribute extensibility - summary
Here's an attempt to summarize what's open on attribute extensibility.
Names just indicate a primary contact for the issue, not necessarily
someone
who signed up to resolve it.
Bruce Esrig
====================
Issues:
(1) Four kinds of extension:
(1a) Simple extension with a new attribute
(1b) Pure specialization where values are pooled among certain
attributes
(1c) Structural specialization where values are treated as separate
for a newly specialized attribute
(1d) Special DITA sense of specialization, where the rules are adapted
for the needs of the specializer
(2) How to implement an evaluator for specialized attributes (Rob A.)
(3) Whether to allow values to specify the mode of specialization that
they intend (Paul P.)
(4) Logic, such as not, but also re-explaining and/or behaviors for the
extended feature (Michael P.)
This is clearly a very rich space of issues. In our discussion on
Thursday,
we made a lot of progress in defining what we need to consider. As a
team,
we haven't yet formed a time estimate of how long it would take to
resolve
enough of these issues to have a definite proposal for DITA 1.1.
Here's a possible approach (Bruce's own thoughts) to resolving the
issues.
1. Agree that all attributes can be conditional.
2. Agree on which extension mechanisms are supported and, in the
language
and architecture, where they appear.
3. Establish a preliminary agreement on how to indicate which kind of
extension
mechanism applies to an attribute.
4a. Clearly describe the current logic based on the new understanding.
4b. Determine what the evaluator would do to implement the resulting
suite
of mechanisms, assuming it could recognize them.
5. Establish a complete syntax description for the extension mechanisms
sufficient to support the needs of the evaluator, both in the
specialized
form and the generalized form.
6. Agree on what additional logic to allow.
7. Determine impacts of the additional logic on the syntax and the
evaluator.
|