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


Hi Stephen,

thank you very much for your feedback on the proposal.

On 01/31/09 02:46, Stephen Peront wrote:
> 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.
> 
> <clips from Michael's email>
> - declares the use of foreign elements in <office:meta> and <*-properties> to be deprecated;

This is indeed new, but has to be compared to the previous version of 
the proposal, which did not allow foreign elements and attributes there 
at all.

I'm proposing to deprecate them on both elements. The reason for 
<office:meta> and <*-properties> are however different.

Regarding <office:meta>: We have added support for RDF/XML metadata in 
ODF 1.2, which among other things, can also be used when meta elements 
have been added to <office:meta> in the past. I think it not reasonable 
to have two alternative ways of achieving the same thing in the long 
term, and that it therefore is reasonable to deprecate the mechanism we 
had previously in favor of the new one we have added for ODF 1.2.

Regarding <*-properties>: Is is my understanding that foreign attributes 
have been used here for formatting properties that were considered to be 
somehow application specific, and therefore have not been proposed for 
ODF, but that in principle could also be added to ODF, only not to ODF 
1.2. My personal opinion is that we as a TC should aim to approve 
Committee Drafts more frequently than in the past, so that implementors 
can claim performance to a particular draft shortly after they have 
proposed their extension, and do not need foreign elements and 
attributes for this purpose any longer. I further think that, if an 
extension is of any value for any other application, that it then should 
be standardized, or otherwise should be stored as an application 
setting, which explicitly have been designed to hold application 
specific properties.

What I would like to mention here is also that I'm proposing a change 
regarding foreign elements also because the way they are specified at 
the moment is not specifiable with Relax-NG and even not with NVDL, what 
I consider to be an issue, too.


> - adds a requirement that conforming producers must be able to produce strict conforming documents on demand.

This requirement is not really new. The previous proposals did not allow 
any foreign elements in the "plain" conformance mode at all, but also 
included a requirement that producers must have a mode where they create 
conforming documents.

> 
> 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.

What kind of extension do you think of, which cannot be represented by 
any of the many other extensibility mechanism that ODF has, like RDFa 
and RDF for metadata, XForms for embedding whole instances from other 
schemas, or application settings?

> 
> 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).
> 
> 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?

First of all, I think that ODF would remain extensible even if foreign 
elements and attributes are not allowed in conforming documents, because 
there are very clear rules now how they should be processed by 
conforming applications. And these rules do not say "If there is a 
foreign element, then signal an error to the user and stop loading the 
document". Instead, they say how consumers should continue parsing the 
document anyway.

So, developers can make their experiments with extension. Vendors may 
even ship products that include extensions. They only must not declare 
that the documents that the applications produces are ODF 1.2 documents.

And while I understand your points, I'm wondering what would happen if 
anyone could add arbitrary extensions to conforming ODF 1.2 documents, 
and would do so. How would we avoid that there are 50 or more solutions 
for one and the same problem? How should an implementor know which 
solutions do exist? And how large would the effort for an implementor be 
to implement all these 50 different variants?

In my opinion, if an extension is more than an experiment and if the 
information that is stored in the extension shall be exchanged with 
other implementations, then the ODF TC must get involved. And if the 
exchange with other applications is not of interest, then I believe it 
is also not an issue if the documents that are exchanged must not be 
called ODF documents.

> 
> 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.

Please let me clarify here that the proposal does only 
disallows/deprecates foreign elements. There are other extensibility 
mechanisms, like XForms, RDF/a and RDF/XML, which are a powerful 
alternative to foreign elements if custom XML schema instances shall be 
embedded. There also are the application settings which continue to exist.

>
> 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.

Do my further explanation dispel your concerns?


Best regards

Michael
> 
> 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
> 


-- 
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


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