RE: [dita] attribute extensibility - summary

[Michael Priestley <mpriestl@ca.ibm.com>]

Thanks for the summary, Bruce. In terms
of a plan going forward, my concern is that a full-fledged solution that
covers all the varieties of attribute specialization is beyond the scope
of 1.1 to solve, and may be better addressed in the context of generally
richer design options in 1.2.

For 1.1, we still have the requirement
for adding new conditional processing attributes, and a proposal already
on the table that does that (it doesn't do everything else we want, but
I'm trying to stick to a more limited scope for 1.1). 

There are clearly still some contentious
issues with the current proposal (specifically, use case 1 of the current
proposal), as follows:
- should ditaval matches on a general
attribute match against its specialized children? (my initial take was
no, but after our talk on Thursday, and further discussion with Paul Prescod,
I'm willing to believe that they should, and that it would be a factor
in choosing whether to specialize off of props vs. further down the hierarchy).
- what should the generalized syntax
be? (I'd suggest we accept Rob A's proposal)

To respond specifically to your plan
points:

>1. Agree that all attributes can be conditional.

I continue to prefer a specialization-based
behavior, where having props as an ancestor determines whether an attribute
is conditional. This should make it easier to understand and exchange documents,
since the intended purpose of the new attributes is made clear through
the document type.

>2. Agree on which extension mechanisms
are supported and, in the language and architecture, where they appear.
I would prefer, for 1.1, to limit ourselves
to domain extension, using the existing domain architecture, and using
1 domain per attribute, for the sake of getting the new attribute capability
with a minimum of change to our overall architecture (eg no new architectural
attributes required). This would be a first step towards more complete
support of new attribute definition in future releases.

>3. Establish a preliminary agreement
on how to indicate which kind of extension mechanism applies to an attribute.
I would prefer to limit ourselves to a single
kind of extension for 1.1: the kind we already have a firm requirement
for and understanding of (the definition of new attributes that are used
for conditional processing in the same way as our existing attributes).

>4a. Clearly describe the current logic
based on the new understanding.
I will add something explicit below

>4b. Determine what the evaluator would
do to implement the resulting suite of mechanisms, assuming it could recognize
them.
Defer to 1.2

>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.
Defer to 1.2

>6. Agree on what additional logic to
allow.
Defer to 1.2

>7. Determine impacts of the additional
logic on the syntax and the evaluator.
Defer to 1.2

With respect to enabling our 1.1 proposal
to handle attribute type specialization, here's a set of proposed compromises
for the 1.1 timeframe:

1. make fallthrough - as described in
my inheritance scenario - the only case (eg exclude audience="programmers"
will be equivalent to also saying exclude (anythingspecializedfromaudience)="programmers").


2. tell people to specialize from props
when they don't want fallthrough behavior (ie if the fallthrough behavior
causes problems, avoid it by specializing props)

3. general guidelines for specializing:
 - if ancestor is informally enumerated
(ie has a documented list of allowed values), then specializations should
support only those values as well, or a subset of those values
- note that attributes should typically
not have doctype-enumerated values since attributes given enumerated values
in doctypes cannot contain multiple values and cannot be further specialized.

Michael Priestley
IBM DITA Architect and Classification Schema PDT Lead
mpriestl@ca.ibm.com
http://dita.xml.org/blog/25

"Esrig, Bruce (Bruce)" <esrig@lucent.com>

04/25/2006 08:44 AM

To	Michael Priestley/Toronto/IBM@IBMCA, Paul Prescod <paul.prescod@xmetal.com>
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.