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: [mailto:]
> 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
> 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
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
