RE: [dita] attribute extensibility - summary

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: <>
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:]
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]