dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [dita] attribute extensibility - summary
- From: Michael Priestley <mpriestl@ca.ibm.com>
- To: Dana Spradley <dana.spradley@oracle.com>
- Date: Tue, 25 Apr 2006 14:53:36 -0400
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
Dana Spradley <dana.spradley@oracle.com>
04/25/2006 02:22 PM
|
To
| dita@lists.oasis-open.org
|
cc
|
|
Subject
| Re: [dita] attribute extensibility
- summary |
|
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.
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]