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: Thu, 27 Apr 2006 15:38:20 -0400
If we don't document the generalized
format as authorable, then there would be no valid way to get this occurrence,
except for an author explicitly messing with the format, which like editing
the class attribute would cause unpredictable results.
In any case, I'd think this would be
something we could flag with an error or warning - an attribute existing
in a half-generalized state can't be considered a good thing.
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/27/2006 03:10 PM
|
To
| Michael Priestley/Toronto/IBM@IBMCA
|
cc
| <dita@lists.oasis-open.org>
|
Subject
| RE: [dita] attribute extensibility
- summary |
|
My discomfort from the authoring
perspective is not really over authoring generalizations. You don't need
to generalize DITA to end up with something like this:
<p props="beer-quality(yuck)"
beer-quality="delicious">This content only pertains to
certain beer qualities</p>
You have a situation where metadata
in both @props and in its specializations both determine the output content.
This information may conflict. What people want from extensible attributes
is the ability to set conditions exclusively in the individual attributes.
As long as you allow stuff in @props, this need is not met. It's not just
a matter of WYSIWYG: people who author/review/edit their content also set
the conditional properties of that same content. Most may want to use the
specialized attributes, but if some smart aleck puts stuff in @props, they
need to understand that too.
In other words, this is a leaky
abstraction: we tell authors "you only need to fiddle with these attributes",
but this is not true. When a user tries to generate preview output using
the Open Toolkit and specifies that content for beer-quality='delicious'
should be excluded, he would want to know why that paragraph above is still
included in the output. At this point, the horrific complexity of @props
bursts out of that attribute and entangles the other metadata attributes
in a bloody spaghetti mess.
I get your point about divergence
from previewed content when links are added, but we're talking about body
content here, not just linking. Topic authors are not responsible for inter-topic
links. But they will care about content that they authored. They will care
when a paragraph appears where it should not, or when a sentence disappears
unexpectedly. Yet we don't want them to worry about the content of @props.
Hence the second point of my proposal.
Chris
From: Michael Priestley [mailto:mpriestl@ca.ibm.com]
Sent: Tuesday, April 25, 2006 11:48 AM
To: Chris Wong
Cc: dita@lists.oasis-open.org
Subject: RE: [dita] attribute extensibility - summary
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]