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 11:47:45 -0400
There is divergence between preview
and output, but only in cases where there is generalized content, which
is certainly an edge case for authoring tools. A possible compromise for
the edge case, short of full preview support, would be to have authoring
applications automatically color orange or something any attribute that
contains generalized values, maybe give a message saying something is going
on beyond normal authoring considerations, and preview will not be fully
equivalent to final output as a result.
Otherwise, if we insist that authoring
preview be fully equivalent to processing preview, then the authoring tool
should be aware of all maps currently in use, and all transform overrides
currently implemented, and have a switch for pdf view vs. html view vs.
eclipse help view etc.
In other words, we already accept a
certain amount of divergence from preview to final output as a result of
using XML and having sophisticated processing streams that can add links,
navigation, and metadata. I would be very reluctant to say we should limit
our processing options to only those expressible by WYSIWYG. Editing generalized
content is an edge case, one that needs to be supported for the sake of
our extensibility/interoperability story but would never be created directly
by an author, so I'm not so sure that it has to be WYSIWYG-enabled for
authoring.
If you think it does need to be enabled,
more power to your editor :-) But I would resist ditching the feature if
you think it can't be enabled in authoring applications, because it remains
an important part of the larger interoperability and interchange story
around 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 11:02 AM
|
To
| Michael Priestley/Toronto/IBM@IBMCA
|
cc
| <dita@lists.oasis-open.org>
|
Subject
| RE: [dita] attribute extensibility
- summary |
|
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
"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]