>
> robert_weir@us.ibm.com wrote:
>
> > 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 see one big problem here. The current draft of ODF 1.2 conformance
> definition is not compatible with ODF 1.0 (and ISO/IEC 26300:2600). I
> don't think that users ODF 1.0 who use foreign element/attributes for
> their extension data will applaud to our TC for ignoring investments to
> their infrastructure in a good faith in a continued evolution of ODF.
>
There are two products defined by the ODF standard: documents and
producers/consumers. My reading of Michael's conformance proposal is that
all conformant ODF 1.0 documents will remain conformant ODF 1.2 documents,
and a subset of conformant ODF 1.0 documents will be conformant to the
strict class of ODF 1.2 documents. So no user of ODF 1.0 who has
conformant ODF 1.0 documents will see their documents become
non-conformant.
However, the producer products, the applications that produce ODF, now in
ODF 1.2 have the additional requirement that they are able to produce
conformant strict ODF 1.2 documents. It doesn't say that they cannot also
produce extended ODF 1.2 documents. It only says that they must be able
to produce strict documents.
Also, any conformant ODF 1.0 document or application, if unchanged, will
remain for all eternity a conformant ODF 1.0 document or applications. We
can't take that away.
> > 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.
>
> I don't think that XHTML is really good example here. If you speak with
> people involved in XHTML creation they today have different opinion on
> usefulness of conformance and strict conformance as used in XHTML -- it
> was one of reasons why XHTML failed -- marketed as extensible but made
> in-extensible by law.
>
I've heard differently. I've heard that XHTML did not take off because
HTML browsers and producers were so lax with enforcing the syntax of HTML
that we ended up with billions of web pages that were not even valid HTML.
Once the cat is out of the bag, it is hard to get everyone back to using
well-formed and valid markup. I'd like to avoid that problem with ODF by
having a strict conformance requirement now, rather than try (and fail) to
add it 10 years later.
> > 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.
>
> If there should be strict conformance in ODF to support simplistic
> applications that do not have to take care about foreign extensions then
> there should be also another conformance level which will allow foreign
> elements/attributes and will guarantee roundtripping of them.
>
OK. I believe Michael's proposal has that. He has two conformance
classes for documents, one which is strict and once which is merely
labeled "conformant" (maybe we should call it "loose"?). The difference
is that the conformant producers of ODF are required to be able to produce
strictly conformant ODF 1.2 on demand. In other words, they are required
to allow the user of the producer the option of whether they want to
extend their documents or not. I think giving the user the choice is
important. Do you see a problem with this?
-Rob
> Jirka
>
> --
> ------------------------------------------------------------------
> Jirka Kosek e-mail: jirka@kosek.cz http://xmlguru.cz
> ------------------------------------------------------------------
> Professional XML consulting and training services
> DocBook customization, custom XSLT/XSL-FO document processing
> ------------------------------------------------------------------
> OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member
> ------------------------------------------------------------------
>
> [attachment "signature.asc" deleted by Robert Weir/Cambridge/IBM]