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] Regarding Conformance Clauses

I don't understand the preoccupation with tooling.  The ODF specification is
clearly implementable because people have done so.  How foreign elements are
dealt with, if encountered, is also something implementations have dealt

Of course the stipulation has to be made in prose.  It is not possible to
know what someone who did want to accept somehow-known foreign elements
would modify their acceptance schema to allow specific ones, and we won't
know how the added-element and attribute schemas merge into the strict
schema.  We also don't know how they handle ones they don't know about but
they want to be graceful with.

If we only provide strict schemas, RelaxNG validators will presumably not
assess documents having anything else as conformant.  That strikes me as
fine.  Assessing documents that have foreign elements and attributes is a
matter for those who want to assess such documents.  I am going to presume
that where there's a will, there's a way.

With regard to the specific behavior of adjusting to the presence of foreign
elements and attributes in accepting and processing a document, I assume
that there is sufficient implementer ingenuity in the world to handle that
if it is desired.

We have, after all, been operating with that definition since 2005 and there
is no evident harm.

 - Dennis

PS: I see no reason to make contortions to satisfy a specific tool.  That is
far removed from the purpose of the ODF specifications, it seems to me.  In
particular, there seems to be no concern that NVDL cannot verify that the
office:mimetype attribute value and the <office:body> content agree.   (Or
the similar question concerning the MIMETYPE item of the package and the
<office:body> element of the <office:document-content> element of the
content.xml part.)

PPS: I don't understand the argument for flipping the default and also
deprecating the office:process-content attribute.  Validity doesn't depend
on whether the content is processed or not.  My understanding of the
validity requirement in ODF 1.1 is that there be a schema-conformant
document left when the element is ignored.  (I assume that means the start
and end tags are ignored and this process is repeated as necessary in the
content that remains.)

-----Original Message-----
From: Michael.Brauer@Sun.COM [mailto:Michael.Brauer@Sun.COM] 
Sent: Monday, January 26, 2009 06:24
To: dennis.hamilton@acm.org
Cc: 'OpenDocument Mailing List'
Subject: Re: [office] Regarding Conformance Clauses

[ ... ]

Let me explain this a little bit further. Foreign elements cannot be
validated with Relax-NG. That is, one cannot write a Relax-NG schema
that allows the embedding of foreign elements anywhere while it at the
same time still validates the elements and attributes defined by ODF,
and their nesting. That's why we describe how these elements are
processed in prose.

With NVDL it would be possible to write a script that allows a
validation of the ODF documents even if it contains foreign elements.
But there is still a problem with office:process-content. Depending on
it's value, a NVDL script would have to specify that the content of the
element that has to be validated or has to be ignored. While NVDL has
these two modes, it can't select the one or the other based on an
attribute value. It can only select one or the other mode based on
element paths. So, while NVDL would allow us to specify whether the 
content of an element is processed for the purpose of validation or 
ignored, it does not allow us to make this decision based on an 
attribute value.

Which means that, if we keep the office:process-content attribute, that
we still cannot develop an NVDL script that validates ODF with foreign
elements. The deprecation of this attribute therefore is a step into the
direction where we can use NVDL for validating ODF documents. And the 
future use of NVDL is actually the reason why I have proposed to 
deprecate this attribute.

[ ... ]

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