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


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.


Inactive hide details for Dana Spradley <dana.spradley@oracle.com>Dana Spradley <dana.spradley@oracle.com>


          Dana Spradley <dana.spradley@oracle.com>

          04/27/2006 03:51 PM


To

dita@lists.oasis-open.org

cc


Subject

Re: [dita] attribute extensibility - summary

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>

          To

          "'Paul Prescod'" <paul.prescod@xmetal.com>, Dana Spradley <dana.spradley@oracle.com>, Michael Priestley <mpriestl@ca.ibm.com>
          cc

          dita@lists.oasis-open.org
          Subject

          RE: [dita] attribute extensibility - summary

          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

GIF image



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