Hi Erik--
Yes, I agree attribute extension by addition and attribute extension by
specialization need to go hand in hand into the architecture, and be
used as appropriately as possible by DITA implementers, the one
complementing the other.
And looking back, I think that is why some of us insisted on not
restricting this enhancement to filtering attributes back in July.
Unfortunately, the solution we've managed to come up with so far for
attribute addition is so weak that I fear we will have to deprecate it
in favor of a more comprehensive solution ASAP - burdening early
adopters with change management issues down the line.
I'd be up for seeing the attribute addition feature through and
replacing the general attribute portion of our proposal with that in
1.1, as I've already indicated.
But so far I don't think I've found any takers - unless this means
you're up for it too.
Hence the proposal to agree in principle that it makes architectural
and practical sense now, but defer further work on it until 1.2.
--Dana
Erik Hennum wrote:
Hi, Dana and Paul:
The challenge for extension by addition could be to preserve
interoperability. Dave Orchard has some interesting things to say about
that problem (though his primary concern is versioning a vocabulary and
integration of arbitrary vocabularies rather than casting within a type
hierarchy).
Anyway, even after we have a good solution for extension by addition,
we will still want to specialize for the cases where there's a common
semantic. Whether I've used an attribute or element, I should be able
to indicate that a javaClassName is a special kind of apiname or that
an individual publisher is a special kind of publisher.
About narrowing DITA 1.1 attribute extension to filtering attributes --
FWIW, when issue 20 was first discussed last July, the consensus was
that attribute extension not be restricted to filtering attributes. As
summarized in a contemporary note (http://www.oasis-open.org/apps/org/workgroup/dita/email/archives/200507/msg00095.html):
Do you think it is reasonable that 1.1 would allow the invention of
whole new elements, and new filtering attributes, but not random
attributes? It seems kind of weird to me. Our customers will tell us
that they need new, proprietary attributes and we'll have to tell them
that they will have to use <unknown>-derived or
<data>-derived elements to simulate attributes.
That seems reasonable to me (thought at this point, I suspect that many
of us are close to trading a spare kidney at this point to close out
DITA 1.1).
Thanks,
Erik Hennum
ehennum@us.ibm.com
PS. I think a mail agent may have inserted a small image at the start
of mail header, which gets carried forward in the replies.
Dana
Spradley <dana.spradley@oracle.com>
You mean drop the general attribute from
the proposal, and limit the scope to just the props attribute used for
conditional attribute specialization in the hierachical method proposed?
Yes, I could agree to that - provided it included some assurance from
all the other people working on this issue that they have no objection
in principle to the notion of attribute addition Erik's paper suggests,
and would support an attempt to include such an enhancement in 1.2 or
1.3.
I do have another question though: Erik's last message came in with a
gif attachment, and now yours has, filename ATT2282822.gif. I haven't
opened either attachment.
Do you guys have a virus or something?
--Dana
Paul Prescod wrote:
I don't think that we can
promise to put a feature in 1.2 before we've scoped it and judged user
demand for it. But I think that it is very likely that you design such
a feature (which seems quite doable) and find a constituency for it
(which seems quite reasonable) then it could go into 1.2 or 1.3.
Would it be sufficient right
now for us to publically document what the current proposal is NOT for,
and in particular that it is NOT designed for adding arbitrary
attributes to specialized elements? This is a use case that we all
agree will not be handled and is therefore deferred until we have a
design and use cases.
It would be great to sieze a
moment of consensus if such does in fact exist.
From: Dana Spradley [mailto:dana.spradley@oracle.com]
Sent: Thursday, April 27, 2006 2:23 PM
To: dita@lists.oasis-open.org
Subject: Re: [dita] attribute
extensibility - summary
I'm sorry, but this really does seem
like low-hanging fruit to me.
What's the point of putting the general attribute in now and support
roundtripping through that, if we could do this instead?
We're not talking about attribute specialization here, but mere
attribute addition.
If we're not doing it now, I'd like to see it in 1.2 - and to see it
done right, I'd like to take the leadership of this enhancement myself.
In return, I would remove my objections to what you're doing with
conditional attribute specialization - since now I can see it in
context as a very targeted solution for a particular kind of universal
attribute, and not as a stalking horse for requiring every added
attribute to submit to some kind of specialization rubric.
--Dana
Erik Hennum wrote:
Hi, Bruce:
About Item 2, I hasten to note that the proposal for extension by
addition for properties is a potential direction rather than something
that's ready for implementation.
For example, we will need to think through the implications of hiding
and restoring additions during roundtripping to the general form and
back to the specialized form. We will want to think through that
problem along with other potential enhancements of the capabilities of
specialization.
I'm confident that, given the minds involved in the DITA Technical
Committee, we will be able to solve those issues, but even I would
agree that they are out of scope for DITA 1.1
My intent with the posting was to suggest in a more concrete way that
we can build on attribute specialization to much greater capability
later on -- not to add more to the DITA 1.1 plate. I'm sorry if I
didn't make that clear.
Thanks,
Erik Hennum
ehennum@us.ibm.com
"Esrig, Bruce (Bruce)" <esrig@lucent.com>
I thought that was the strength of it ... no action items!
I thought I was clearing away side issues, leaving the following:
Item 1. Michael's proposal
Item 2. An alternate proposal, yet to be named (see next paragraph)
Item 2. Now that Dana Spradley has extracted the attribute extension
thoughts from Erik's "Extreme" paper, we seem to have two viable
approaches on the table.
I had not realized that specialization of an element could both
- restrict the content
- add attributes
So we'll need to look at that.
Bruce
|