I don't follow Michael.
How does limiting the scope as Chris suggests amount to "ditiching
specialization?"
It still provides a mechanism for new conditional attributes through
the props attribute.
--Dana
Michael Priestley wrote:
If we introduce a new extension
mechanism
that is not specialization, we will need to consider, among other
questions:
- how are the extended values
preserved
during generalization? are they even affected by generalization? if
yes,
isn't it specialization? if no, haven't we just broken our entire
extensibility/interchange
model?
- how is the use of these attributes
signaled to processes that care about doctype differences, eg conref?
or
are they ignored? if ignored, how can we tell whether two topic types
are
truly content-model compatible? if not ignored, do we add the info to
the
domains attribute? if yes, isn't it specialization? if no, do we need
another
architectural attribute?
Specialization is designed to solve
a whole range of processing implications to reconcile customized
doctypes
that need to be interchanged. If we ditch specialization for this case,
those problems get bigger, not smaller. If we ditch both specialization
and stop caring about the problems it solves, then we break most of the
promises that have been made about DITA in its charter, spec, etc.
As it says in the proposal, this is
for conditional processing attributes (which are universal), and for
arbitrary
tokenized universal attributes. Our requirement for 1.1, as ranked by
both
the TC and by public input, is to provide a mechanism that allows new
conditional
attributes. We allowed in the arbitrary tokenized universal attributes
as a "if we enable it for conditional attributes, the same logic will
apply to other attributes that have the same occurrence pattern and
syntax,
so it's free for that case".
I am honestly trying to solve as
small
a problem as possible, without breaking DITA's basic architectural
promises.
That's why it's limited to only two cases, that's why we ditched the
scope
and negative value use cases, that's why I'm continuing to focus on
attribute
type specialization and not attribute value specialization, but I don't
think making the problem so small that it excludes specialization is
possible
without the entire solution becoming something other than DITA.
Michael Priestley
IBM DITA Architect and Classification Schema PDT Lead
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25
I agree with Chris's take on the appropriate scope for
1.1.
While I admire Michael's desire to realize the larger promise of
specialization
in this feature immediately, I think that would be more appropriate in
a 1.2 or even 2.0 timeframe, when we've all had a chance to consider
the
implications fully.
We're already limiting general attibute extensibility to NAME values so
it can be accomodated by the simplified syntax originally proposed for
conditional attribute extensibility. Yet now we're busy complicating
the
conditional case considerably, raising the question of why a dedicated
syntax for the general case was judged out of scope originally.
Also the model proposed for full-fledged attribute specialization here
is appropriate only to conditional attributes. If we are going to
include
a coherent and consistent approach to specialization for attributes as
part of this proposal, it should apply to all kinds of attributes, not
just conditional processing ones.
--Dana
Chris Wong wrote:
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
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.
|