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: "Chris Wong" <cwong@idiominc.com>
- Date: Tue, 25 Apr 2006 10:10:52 -0400
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.org>
|
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]