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
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.
|