Re: [office-comment] Foreign elements and attributes

[Jesper Lund Stocholm <4a4553504552@gmail.com>]

Dennis,

2009/2/9 Dennis E. Hamilton <dennis.hamilton@acm.org>:
> Jesper,
>
> Do these organizations allow their extended documents to leak into
> interchange, under the assumption that there is no harm because use of the
> feature will be ignored and cause no harm?

Well, as I understood the cases I have heard of, these extensions do
not carry sensitive information. They simply contain conditional
markup that is shared  between coorporating entities (and they share
an understanding of the semantics of the extensions as well, of
course).

Rob,

> If the ODF Standard stated that such extensions were not conformant,
> would these private, internal to an organization, extensions cease to
> occur?  Or will it still continue?  I'd imagine it would still continue.

I agree with you that they would propably still be there. The
advantage of having the extension mechanism, though, is that it
enables organisations to extend the format to suit their needs. Yes,
if they need to use the extensions to coorporate with contractors,
their partners will need to understand the extensions as well. But the
advantage of having extensions "allowed" in the spec is, that you can
almost have your cake and eat it too. By using the built-in extension
mechanism you can add value to the document format and still be able
to pass the documents around to third parties. And no, if the third
party does not understand the extensions, they will not gain from it.
But the document will not break when loading (you can call it
"graceful propagation"). If you remove the extension mechanism from
the format, documents with "illegal" extensions will break when loaded
on systems that cannot understand it.

If the argument is that "they will do it anyway", wouldn't it be
better to have a standardised way of doing these things?

I remember when we dealt with processing OOXML i n SC34 and there was
the issue with printer blobs having a placeholder somewhere in OOXML.
The "problem" with this was that these blobs are
platform/application-specific and the argument against it was that
this had no place in a standard. The argument for it was that vendors
actually will need/wish to save printer blobs in the document, so it
would be better to have a specific place for them. Now, ODF does not
have the possibility of saving these printer blobs in the document
format, and the result is that vendors then save these blobs somewhere
else. As an example, Lotus Symphony will actually save a
Base64-encoded binary blob in the config-item-set with the name
"printerSettings", AFAIK. I'd much prefer to have a standardised way
of doing "nasty things" instead of leaving it at the discretion of the
vendors.

As I said before, extensibility is an interop nightmare. But taking
extensibility out while still acknowledging that vendors will extend
it anyway is imo an even bigger interop nightmare.

Jesper Lund Stocholm
www.idippedut.dk
WG4