dita — archive

RE: [dita] attribute extensibility - summary

From: Christopher Wong
To: [email protected]
Date: Tue, 25 Apr 2006 13:41:00 -0000

MHonArc v2.5.0b2 -->

dita message

Subject: RE: [dita] attribute extensibility - summary

From: "Chris Wong" <[email protected]>
To: <[email protected]>
Date: Tue, 25 Apr 2006 09:44:25 -0400

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:[email protected]]
Sent: Tuesday, April 25, 2006 8:44 AM
To: 'Michael Priestley'; Paul Prescod
Cc: [email protected]
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 <[email protected]>