[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dita] attribute extensibility - summary
Yes - just want to echo Michael's comment about the processing. I've worked
out most of it using XSLT pseudo-code, picking XSLT simply because I was
asked to show that it could be done there.
I think there are a couple of reasons nobody uses the existing otherprops
syntax. First, nobody wants to author the syntax. Second, most (all?) tools
don't support it, partly because it was never clear how to reference the
values in a ditaval file. I think this proposal takes care of both
problems. For authoring - people will author the values as new attributes.
The generalized syntax is there primarily for interchange. It will always
be possible to author directly in @props, but I think this is the
way-out-on-the-edge case. For processing - the new proposal clarifies that
the specialized attribute is simply listed in the ditaval the same way as
existing filter values.
Robert D Anderson
IBM Authoring Tools Development
Chief Architect, DITA Open Toolkit
(507) 253-8787, T/L 553-8787
Michael Priestley
<mpriestl@ca.ibm.
com> To
"Chris Wong" <cwong@idiominc.com>
04/25/2006 09:10 cc
AM 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
"Chris Wong" <cwong@idiominc.com>
04/25/2006 09:44 AM To
<dita@lists.oasis-open.o
rg>
cc
Subject
RE: [dita] attribute
extensibility - summary
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]