Re: [office-comment] Foreign elements and attributes

[rjelliffe@allette.com.au]

Murata Makoto wrote:
> I believe that foreign elements and attributes should be allowed.  This
> looks obvious to me.
>

Rob Weir wrote:
> We've had this feature in ODF since 2005.  But even though we've
> had many programs implement ODF, they have not used this feature.
> In fact, all of
> the implementations I know of will simply strip out any foreign markup
> it  encounters.  So if it is such a useful feature, how come in 3 1/2
> years no one has bothered to find a use for it or to support it in
> their products?  That's why I favor removing it from the ODF core.
> Having it there just makes work for implementations to write code to
> handle it "just in case", even though no one currently uses the feature.

Because

A) if it is not in the products, ordinary developers cannot use it, can they?

B) I think Rob is using "no-one" exclusively to mean suite/application
developers, rather than developers who are system integrators. That Sun
and IBM have no use for this or cannot justify it in monetary terms is
their business. But there are indeed other system integrators who would
like such a feature.

Readers of this list should be aware that there is a small but thriving
community of system integrators who use XML (and before that SGML)
entirely based on custom schemas: many heavy industries and organizations
run on these custom systems (military, aerospace, pharmaceuticals,
defense, legal.) These industries are not "mass market" in the sense that
they are something you would see in CNET or ComputerWorld. However, they
are incredibly important. It would be quite mistaken to view the
extensibility issue through the paranoid glasses that the only question
that needs to be asked is how to keep ourselves safe from Microsoft.
(Especially given, of course, that the minimal schema would not actually
do that in the slightest, but is just window-dressing.)

I have had three use cases where this issue was a showstopper for ODF, due
to the incorrect implementation of this feature.

The first was for for a particular branch of our Department of Defense,
asking whether they could integrate ODF or OOXML applications for their
XML/SGML based system, which has been in use since the mid 90s. Even
though there were some good features in ODF 1.1 and OOXML (XForms, etc),
they *both* variously lacked enough metadata or structuring capabilities
for me to recommend in that processing chain, which is a shame.

The second use case was to represent XBRL documents in a standard document
format. OOXML SpreadsheetML could not do it. ODF 1.1 could not do it.
However OOXML WordProcessingML could in fact do it.

The third was for a web-based collaboration environment, where we hoped
that if it adopted ODF as its internal format, this would help it with
handling documents with rich markup. The requirement was for
round-tripping, and integration into other non-web based tools.
Unfortunately, due to ODF implementations' poor support for the ODF
standard in this regard, it was not really feasible.

I found and reported a bug with OpenOffice in this regard, and have IIRC
notified the ODF TC that the old text was incomplete in this regard (I
think Florian Reuter of Novell made a follow up comment to me.) I suppose
it is nice if you have a bug that you can find some flimsy excuse to get
it made part of the standard, rather than having to fix your code and
delivering the functionality that was decided as necessary by the initial
ODF TC!

(Again, I note that I have no objection to the current wording of the
committee draft: having it as a logical category and output option, as
long as all ODF systems are required to read and correctly strip etc
extended-schema-documents.)