OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

office message

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

Subject: RE: [office] A few of specific examples

An interesting topic.

I will say that we are not talking about necessarily arbitrary nor
proprietary extensions (and the proposed requirement to document deviations
sounds like an interesting gate).  I am not otherwise going to address the
good-vs-evil argument.  

In existing language, there is the requirement that after the described
process of elimination occurs, there be a strictly-conforming document
underneath.  I think that is strong guidance to implementers about playing
safe and also wanting to maintain interoperability (if they so desire) with
conforming consumers that will not interpret the extension.  Also, adding
strictly-compliant documents should assuage those concerns that very
communities of practice and interoperability might have about the damage to
interoperability that foreign-elements and attributes might represent.

I can see a variety of useful ways to make use of such a thing with the
understanding of what the likely foreign-element treatment will be.  I can
also see how such provisions help with down-level use of up-level documents
and even with first-step ODF 1.2 implementations that, say, haven't figured
out how to support <text:meta> or xhtml:about just yet.  (I'm not sure it is
kosher to ever call an xml:id a foreign attribute, but I'll play along with
that for now.)  I don't know why an indexer can't do that -- most have ways
to figure out what is index-appropriate content and what isn't -- and why a
strict-only scrubber can't do that too.  (It won't help know if scripts are
malicious of course, or whether there is an Easter egg or some
covert-channel payload buried in RDF markup or an OpenOffice.org
alternative-rendition binary, but so be it.)

With regard to your affirmative proposal to look at extension mechanisms, I
think that is an interesting idea for the future.  When such a mechanism has
been arrived at will be a good time to assess deprecation of the foreign
element-attribute-value provision. 

 - Dennis

-----Original Message-----
From: robert_weir@us.ibm.com [mailto:robert_weir@us.ibm.com] 
Sent: Tuesday, February 03, 2009 16:50
To: office@lists.oasis-open.org
Subject: [office] A few of specific examples

Some specific examples of how and why arbitrary proprietary extensions are 

[ ... ]

Now I can imagine a well-thought out extensibility mechanism that would 
address the above concerns.  I'd certainly entertain any such proposals. 
But merely saying "The X in XML standards for eXtensibility" is not a 
considered engineering approach.   Extensibility requires that we think 
out issues such as versioning, content negotiation, fall-backs, 
namespacing, round-tripping, as well as offer clear guidelines for how 
extensions declare whether they contain translatable text, metadata, 
executable code, or other categories of importance.  The fail-safe 
approach is to remove this option until such time as we can do it right. 

If there is sufficient interest to work on this, we could create a new 
subcommittee on extensibility to work on developing a detailed proposal in 
this area, obviously for consideration post ODF 1.2.


To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:

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