Rob,
I like this idea of having a better engineered extension mechanism that allows the same capabilities as ODF 1.0, but structured in a way that avoids the
Liabilities. To merge threads, here are your comments from another recent exchange on this topic, which I agree with:
> Correct me if I'm wrong, but I don't recall anyone proposing to add customXML in the sense of OOXML, to ODF. I think customXML, and the specific semantics behind it,
> are reasonable, and if TC members want that functionality in ODF, then it should be supported in a first class way rather than via generic mechanisms like bookmarks.
> It would not be too hard to clone such a feature from what is described in OOXML.
Regarding how long we'd be willing to wait for such functionality, I think we could clone the IS29500 approach pretty quickly. That doesn't address the issue of extensions in existing implementations that may already use foreign elements, as others have alluded to, but I think the addition of customXML functionality would be a good thing to do.
- Doug
Original Message-----
From: robert_weir@us.ibm.com [mailto:robert_weir@us.ibm.com]
Sent: Monday, February 09, 2009 10:58 AM
To: office@lists.oasis-open.org
Subject: Re: [office] Re: ODF Conformance
So we have elements, attributes and attribute values. My understanding is
that the conformance clause talks about foreign elements and attributes. I
don't think it says anything about prefixed attribute values,
I'd interpret this as saying:
1) If the schema defines an enumeration for the values of an attribute,
then those and only those values are valid. Any values outside of that
enumeration, including prefixed ones would be invalid to the schema, and
therefore not conformant.
2) If the schema assigns a single type like "string" but the text of the
specification states that only a specific set of values are permitted, but
ones which cannot be all listed into the schema, like country codes, or
mime types, then any values outside of that list , including prefixed ones
would be not conformant.
3) If the schema and specification allow any values then any values are
OK, including namespace prefixed ones. In fact, prefixed names would be
preferred since they help avoid collisions.
So, I think the draw:engine case would be conformant. The music:shape one
would conform to the "extended" conformance class, but would not conform
to the default conformance class. That's how I read the proposal.
The intent is to get away from open-ended extension mechanisms and replace
them with more targeted ones that better express the intent. For example,
we could define a shape extension mechanism, or a schema that generally
specifies an alternative XML encoding of the same content (MusicML versus
SVG). But without such a mechanism, an app has no idea whether the
foreign element is a script that should be removed for security reasons,
something that has accessibility consequences, something that must be
translated when the document is translated, or whether it contains
personal metadata that should be removed when anonymizing the document.
So I guess my questions are:
1) Is it worth having a better engineered extension mechanism that allows
the same capabilities as ODF 1.0, but structured in a way that avoids the
liabilities?
2) If so, how long are we willing to wait for it to be designed and
specified? I think it would probably take a 4-6 weeks. We could likely
get back to a single conformance level if we had a better designed
extension mechanism.
I have nothing against extensions per-se. I just want to ensure that they
are done in a way which will scale with broader ODF adoption and not
create problems that we'll never be able to solve. This is one of those
things we need to get right.
-Rob
Thomas Zander