MHonArc v2.5.0b2 -->
dita message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [dita] attribute extensibility - summary
From: "Chris Wong" <>
To: "Michael Priestley" <>
Date: Tue, 25 Apr 2006 11:02:53 -0400
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:]
Sent: Tuesday, April 25, 2006 10:11
AM
To: Chris Wong
Cc:
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
http://dita.xml.org/blog/25
"Chris Wong"
<>
04/25/2006 09:44 AM
To
<>
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:]
Sent: Tuesday, April 25, 2006 8:44
AM
To: 'Michael Priestley'; Paul Prescod
Cc:
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.
Follow-Ups:
Re: [dita] attribute extensibility - summary
From: Dana Spradley <>
RE: [dita] attribute extensibility - summary
From: Michael Priestley <>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
