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


But specialization of what...element or attributes?

If done as specialization of attributes, I disagree: it *does* have major architectural implications - not only in DITA, but in XML itself - since in the XML spec, as I've previously said, attributes are always subordinate to a particular element, and don't float free as things in their own right.

And at least as I've been hearing the discussion, this enhancement has been pitched lately as adding a new and unprecedented specialization method for attributes - requiring you, as you've several times admitted, to think long and hard about how that would make the most sense.

--Dana

Michael Priestley wrote:

1) I have never claimed this proposal is a general solution for attribute specialization. The title has changed over time to try to remove ambiguity ("metadata attributes" was the original title, but that caused some confusion) but the core requirement has always been extensibility of conditional processing attributes.

2) It has no major architectural implications IF it is done as specialization, which at least in other contexts has always implied unlimited levels and generalized processability.

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



Dana Spradley <dana.spradley@oracle.com>

04/26/2006 11:46 AM

To
dita@lists.oasis-open.org
cc

Subject
Re: [dita] attribute extensibility - summary







Fine. Then why try to claim this proposal amounts to a full-fledged proposal for something unprecedented in DITA - attribute specialization, something appropriate to be unveiled in a major release - when it's really just a narrowly targeted fix to allow for additional universal attributes to be added to elements - in particular, conditional processing attributes - that has no major architectural implications?

That's the kind of proposal that would be appropriate for a point release like this.

Now when our users requested this enhancement, did any of their requests include anything that couldn't be handled by the compromise scope Chris Wong proposed? Was there anything in these requests that would require the more extensive scope added in the last couple of weeks?

If not, then why are we engineering stuff into this feature that our users aren't even demanding yet?

Perhaps a better approach would be to limit the enhancement to Chris's scope for now - but provide a "possible future direction" note in the spec that would explain and preserve the expanded scope - and ask any users out there who need this further enhancement to contact us before the next point release so we can further consider it?

If no one contacts us, then we don't need to engineer this feature any further.

And yes please, could you send me urls to Erik's presentations on general attribute specialization? I'm also interest in seeing the most elegant solution possible adopted for the general case, without undue complication.

--Dana


Michael Priestley wrote:


We actually did do exploratory work on full attribute specialization, and there have been some thought experiments undertaken by Erik Hennum on what a full solution might look like - I'll defer to Erik to provide URLs to some of his presentations.


But the very minimum that would be required to allow per-element new attributes would be per-element tracking of new attributes, which would mean a new universal attribute for tracking attribute ancestry - effectively, adding something like the domains attribute to every element. This would affect generalization, conref, and domain integration rules substantially, in a way that the current much more limited proposal avoids.


Also, keep in mind that the number one requirement for the next release of DITA is not the ability to add arbitrary new attributes on a per-element basis: it is the ability to define new conditional-processing attributes. So I think we are addressing requirements in the order prioritized for us by our users, as well as in the order that requires the least architectural rework in a point-release of the standard.


Michael Priestley
IBM DITA Architect and Classification Schema PDT Lead

mpriestl@ca.ibm.com
http://dita.xml.org/blog/25

Dana Spradley <dana.spradley@oracle.com>

04/25/2006 02:22 PM


To
dita@lists.oasis-open.org
cc

Subject
Re: [dita] attribute extensibility - summary









True, Michael - but currently in DITA specialization is something that applies to elements alone, not attributes.

And I guess what I'm really resisting is the attempt to use this feature to define a new kind of specialization for attributes alone, before we really understand what we're doing.

As Paul has repeatedly pointed out, in XML attributes are properties of elements - they have no independent existence of their own.

An attribute of the same name can, in XML, have a different datatype, and different optionality, even a different list of enumerated values, depending on the element with which it is defined.

The fact that we can use a parameter entity to define a collection of universal attributes and put that entity in the attlist of every element has, I think, started to blind us to the fundamental architectural dependence of every attribute on the element who attlist defines it.

Now I admit that we've gone too far down this road to get specialization of elements through new attributes by any other method than the one we're pursuing here in a 1.1 timeframe - and as such I'm happy to go along with the compromise scope Chris has proposed.

But if we had it to do over, I think we would have been better off to enhance element specialization by adding new per-element attributes first, before we defined enhanced element specilization  by adding new universal attributes, as we are attempting to do now - in my most charitable construction of the proposal.

--Dana


Michael Priestley wrote:


You're right, I'm shying at shadows. Chris is not proposing to ditch specialization. But he is proposing to limit specialization in ways that make me question whether it's still specialization:


-  currently in DITA, specialization means any number of levels

-  currently in DITA, generalization means creating a version of the content that conforms to the ancestor type declarations while preserving the processable semantics of the descendant declarations

- if our conditional processing support doesn't meet these definitions, can we still call it specialization?


We do have a design currently proposed that allows any number of levels, and describes how to process the attributes in their generalized form. And I don't think the argument that it compromises WYSIWYGness is a strong one, given the edge-case status of someone directly editing generalized content.

So I'm resisting increasing the scope, because I think we're already stretched to the limit in what we can cover in this feature for 1.1, but I'm also resisting decreasing the scope, inasmuch as that compromises the existing published statements about specialization and generalization.


Michael Priestley
IBM DITA Architect and Classification Schema PDT Lead

mpriestl@ca.ibm.com
http://dita.xml.org/blog/25
Dana Spradley <dana.spradley@oracle.com>

04/25/2006 01:00 PM


To
Michael Priestley/Toronto/IBM@IBMCA
cc
dita@lists.oasis-open.org
Subject
Re: [dita] attribute extensibility - summary











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
Dana Spradley <dana.spradley@oracle.com>

04/25/2006 11:57 AM


To
dita@lists.oasis-open.org
cc

Subject
Re: [dita] attribute extensibility - summary













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
"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?
  • @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.




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