OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dita message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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



"Chris Wong" <cwong@idiominc.com>

04/25/2006 09:44 AM

To
<dita@lists.oasis-open.org>
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? 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.



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]