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: Thu, 27 Apr 2006 15:10:00 -0400
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:]
Sent: Tuesday, April 25, 2006 11:48
AM
To: Chris Wong
Cc:
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
http://dita.xml.org/blog/25
"Chris Wong"
<>
04/25/2006 11:02 AM
To
Michael
Priestley/Toronto/IBM@IBMCA
cc
<>
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:]
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: Michael Priestley <>
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
