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] Conformance Definitions


Stephen Peront <stepper@microsoft.com> wrote on 01/30/2009 08:46:44 PM:
> 
> Hi Michael (and TC members)...
> 
> When we discussed the conformance topic in the last TC call; we 
> (Eric and Stephen) mentioned that while a single level of 
> conformance is a good goal, we had concerns about how this would 
> impact the documents and processes that already exist. After 
> watching the discussion on this topic over the last two weeks, it 
> seems that the decision regarding levels of conformance has 
> uncovered two impact topics that are of great concern to us.
> 

Hi Stephen,

I don't think you've been properly welcomed to the TC yet.  You might want 
to send out a note and introduce yourself.  There are many more members on 
the list than can regularly attend TC calls. 

I realize that it may be intimidating to join the ODF TC so close to the 
end of this multi-year ODF 1.2 release cycle, with so many participants 
more experienced and more knowledgeable about the ODF standard, and the 
many past discussions we've had relative to these topics.  But please 
stick in there.  We've all been there.  It will take a while to gain 
familiarity with the standard and what discussions and decisions have 
previously been made, and why, but that knowledge will come with time. But 
I do applaud your efforts of voicing your strong opinions after attending 
only two TC calls.

> <clips from Michael's email>
> - declares the use of foreign elements in <office:meta> and <*-
> properties> to be deprecated;
> - adds a requirement that conforming producers must be able to 
> produce strict conforming documents on demand.
> 
> There is a class of potential extensions that will never be 
> appropriate for integration into a broad standard like this, and 
> there needs to be a mechanism by which such extensions can co-exist 
> with the main specification and the documents can remain conformant.
> Does the ODF TC want to get into the business of having to be the 
> central arbiter/repository for those very narrow extensions. It 
> makes sense for the TC to allow them to exist.
> 

You have not argued that such extensions should be conformant, only that 
they may be useful.  I think these are two very different things.  It is 
not a requirement that an ODF document should be capable of all useful 
things, whether defined by the ODF standard or not.  It is only required 
that the ODF Standard define what exactly a conformant ODF doc is. 

I think it is instructive to look at the W3C XHTML Recommendation.  It 
defines an extensibility mechanism, via XML namespaces, but does not 
permit such extensions in conformant documents.  Similarly, OOXML defines 
some extensibility mechanisms, like custom import parts, but not in 
conformant documents.   I don't think anyone is denying the usefulness of 
an ODF extensibility mechanism, or even whether the extensibility 
mechanism should be defined in the standard, but only whether such 
mechanisms may be used in conformant documents.

> We believe that extensibility is very important to file formats. The
> X in XML does stand for extensible, after all.  Is the ODF TC 
> proposing to switch to inflexible markup language perhaps? (IFL?). 
> Of course, I am only joking about the last question... However, the 
> power of ODF as a file format is that it is extensible. The decision
> to deprecate this feature seems to be in direct conflict with the 
> goals that we are trying to achieve in the OIC TC. How are ODF 
> documents able to achieve true interoperability if they do not allow
> foreign elements? (Remember, that they will no longer be called 
> "ODF" documents if they use foreign elements).
> 

Can you give a a few examples of where allowing foreign content in 
conformant ODF documents would improve "true interoperability" between ODF 
applications?

> In talking with the developer community, who will own the 
> responsibility of creating systems, processes and applications that 
> can consume/produce ODF documents, it is evident that the use of 
> foreign elements is a breeding ground for things that might 
> eventually belong in the spec, which leads to an evolving 
> specification that keeps getting better. In the last TC call, I 
> heard someone make the argument that "people can join the TC and 
> make proposals". At first this sounds like a great idea; however, is
> it a realistic one? Do most developers even know that this TC 
> exists? Is OASIS prepared to support 1,000's of developers joining 
> the TC? Is this TC prepared to receive, discuss and decide on the 
> 10's of thousands of proposals that could come from that approach?
> 

Again, something being useful is not a criterion for whether something 
should be conformant.  As you've pointed out before, the X in XML is for 
eXtensible.  But aside from generic processing by an XML parser or similar 
tools, there is no significant processing of XML-as-XML that can be done 
absent a schema. It is all skin and no spine. It is the schema that 
defines the constraints that allow tooling and give the document meaning. 
Without that schema, preferably defined in a standard, the processing of 
that XML is severely limited.

Even when you talk about the usefulness of extensions to developers, you 
must agree with me that such extensions are equally opaque and inscrutable 
unless the schema of the extensions are defined and shared among the 
producers and consumers of those extensions, even if informally. As such, 
even extensions are implicitly defined, though privately, and outside of 
the standard.  I believe that such arbitrary, informal and private schema 
definitions, outside of the standard, should not be allowed in a 
conformant document, since they cannot possibly be the basis of 
interoperability derived from what the standard actually defines.  We 
can't standardize what two parties do via the private exchange of a 
proprietary extension schema, so we shouldn't say it conforms to the 
standard we are writing. 

> We think it makes sense to have a conformance class wherein such 
> extensions are explicitly disallowed (like the "strictly conforming"
> class in the document), and to require that extensions are 
> implementation-defined (i.e. have to be documented by whomever 
> produces them, vs. left unspecified), and to remove a requirement 
> for round-tripping any unknown content (which is a lot of the 
> proposal). We think that if the conformance clause does allow 
> extensions, it will mitigate some of the concern with some language 
> clarifying that extensions cannot be used to replace something that 
> can be specified using markup defined in the spec, only to specify 
> something that's not part of it.
> 

We obviously disagree on this, but I believe understand your points.  I'd 
rather have consensus on this, and we should see if discussion brings us 
any closer to a consensus proposal, but lacking that we'll have a vote.

> We can discuss this more via email and in the TC call on Monday. 
> However, we are not able to support this TC in adopting the 
> conformance clause as it is written in the current revision.
> 

I understand.

> Hope you are doing well!
> 
> Cheers,
> -Stephen
> 
> -----Original Message-----
> From: Michael.Brauer@Sun.COM [mailto:Michael.Brauer@Sun.COM]
> Sent: Wednesday, January 28, 2009 6:34 AM
> To: OpenDocument Mailing List
> Subject: [office] Conformance Definitions
> 
> Dear TC members,
> 
> first of all, I would like to thank you for the valuable feedback I got
> after we have discussed the proposal in the last TC call.
> 
> It seems to me that there are no objects for having only a single
> conformance level which does not allow foreign elements and attributes,
> but that there are concerns to immediately forbid foreign elements
> within <office:meta> and in particular also <*-properties> elements,
> where ODF 1.1 explicitly allowed these elements.
> 
> I have updated the proposal[1] to reflect this, where I have taken the
> variant which did only define a single conformance level as basis.
> However, I have re-introduced the notion of a strictly conforming
> document, which means that there are two levels again. The one of a
> conforming document, and the one of  a strictly conforming document. A
> conforming document is one that does allow foreign elements and
> attributes within <office:meta> and <*-properties>, and only there,
> while a strictly conforming document does not allow foreign elements and
> attributes at all. The differentiation is made again using a strict and
> a non-strict schema. In this regards, there is no change from ODF 1.1.
> 
> The proposal further
> - declares the use of foreign elements in <office:meta> and
> <*-properties> to be deprecated;
> - indirectly adds a requirement to document their use by declaring their
> semantic to be implementation defined.
> - adds a requirement that conforming producers must be able to produce
> strict conforming documents on demand.
> 
> I would like to discuss the proposal, and in particular the three items
> above, in the next TC call. And unless the proposal requires larger
> modifications, I would like to ask for a ballot on the proposal in this
> call.
> 
> Best regards
> 
> Michael
> 
> [1]
> http://www.oasis-open.org/committees/download.php/30932/conformance-
> definition-proposal-v7.odt
> --
> Michael Brauer, Technical Architect Software Engineering
> StarOffice/OpenOffice.org
> Sun Microsystems GmbH             Nagelsweg 55
> D-20097 Hamburg, Germany          michael.brauer@sun.com
> http://sun.com/staroffice         +49 40 23646 500
> http://blogs.sun.com/GullFOSS
> 
> Sitz der Gesellschaft: Sun Microsystems GmbH, Sonnenallee 1,
>            D-85551 Kirchheim-Heimstetten
> Amtsgericht Muenchen: HRB 161028
> Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
> Vorsitzender des Aufsichtsrates: Martin Haering
> 
> ---------------------------------------------------------------------
> 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:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
> 
> 
> 
> ---------------------------------------------------------------------
> 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:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php 
> 



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