Thomas Zander <> wrote on 02/12/2009 06:51:39 AM:
>
> On Thursday 12. February 2009 11:49:33 ext wrote:
> > > I've asked in another mail for your reason to drive this proposal.
> > > Please give
> > > a usecase where the current ODF conformity clause will give us
headaces.
> >
> > > I don't see them and I will never be convinced to take away useful
and
> > > good features unless I see a good reason where it ends up hurting
more.
> >
> > Sorry, we must have missed each other's messages in the traffic. I
> > addressed the specific kinds of problems caused by the general
mechanism
> > in this note:
> >
> > http://lists.oasis-open.org/archives/office/200902/msg00070.html
>
> That mail just posts some anonymous element; thats not a usecase.
> I can't even argue that the "foo:bar" is or is not a loss if an
> implementation
> ignores it since you don't give a realistic usecase to argue from.
>
But that's the important point. From the perspective of an general ODF
consumer, say a word processor, these private extensions are opaque,
without any discernible semantics, just like foo:bar. The consumer is
only able to make very general assumptions -- the extension is well-formed
XML -- but this is insufficient to make even the most basic judgements
about how the extension behaves when the extended content is copied,
edited, split, combined, etc., the most basic editing operations. As I
showed, given such arbitrary extensions, the general consumer is pretty
much forced to drop all extension markup.
> > Now, you might very well say, "But here are N specific examples where
this
> > is not a problem". But that proves my point.
>
> I'd rather call a real usecase where things go really wrong 'proof' ;)
>
The entire point of my criticism is that the consumer of an extended
document just sees arbitrary XML. It has no knowledge of use cases, of
what that extension is for. It just sees foo:bar. It is a black box.
> > If those N specific
> > examples can be written using a more targeted extension mechanism,
then we
> > can get the benefits without the liabilities.
>
> Hmm, there is an assumption in there where we can properly create
anextension
> mechanism for all usecases.
> I notice that in the linked mail you were under the impression that
nobody
> uses this feature in the first place. Which turns out to be a
> misunderstanding, KOffice has used it for years.
>
> I have given 4 examples where we currently use namespaced extensions in
my
> mail 2 days ago. One is legal, one *may* be made into an extention if
we see
> an advantage to that, and two proper and current usecases are not even
> addressed. Meaning that if we forbid their usage KOffice might have to
look
> at not using pure ODF as its native fileformat. That can't be the
intention.
>
> Can I ask you to reconsider your proposal based on the new
> information that we
> use extentions using namespaces in more than one implementation (I named
3)
> already and in a variety of places in the XML tree which defies a clean
> extention mechanism ?
>
I'm hoping we can capture the current use of extensions in ODF
applications on the wiki here:
http://wiki.oasis-open.org/office/Extensibility_Mechanisms
I added some initial items. Are there other mechanisms used by KOffice?
Once we have a good view of what mechanisms are in use, then we can better
discuss whether more targeted least-power approaches are more appropriate
rather than the all-powerful nuclear death ray gun approach.
I know that "least-power" may be unintuitive. Why would we ever want to
do something less than the most powerful extension mechanism possible? But
I think we need to look at power from the perspective of the application
consuming ODF as well. The more constrained the extensibility mechanism,
the more assumptions the ODF consuming application can make, and that
allows it to make more powerful decisions on how to process the extended
documents. We need to balance these concerns.
Regards,
-Rob
