Dennis,
On 01/26/09 04:00, Dennis E. Hamilton wrote:
> Michael,
>
> 1. I am interested in having the foreign element definition and the
> processing procedure be the same as the one in ODF 1.1. The one proposed
> for ODF 1.2 is different and also flips the meaning of the
> office:process-content attribute. I see no justification for making that a
Does it? The wording is a little bit different, but I can't see
where it's meaning is flipped. Or is what you mean the the default value
of the attribute in ODF 1.1 is "true"?
> breaking change, especially if such foreign elements were seen by an ODF 1.1
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.
But if we deprecate the office:process-content attribute, then the
question is what should be the behavior of consumers when they find
foreign elements. It then appears to be reasonable to process their
content within text content (paragraphs and headings), because it can be
assumed here that these elements contain text that is text content, and
that therefor should be displayed.
In all other cases, it can be assumed that displaying text content would
be an error, and it therefore appears to be reasonable to ignore the
content of the element.
> processor, or (originally) created by an ODF 1.1 processor. Maybe we should
An ODF 1.2 producer that uses foreign elements within text content and
does not want their content to be interpreted still may attach an
office:process-content=false. Anyway, I would not recommend to uses such
foreign elements within text content.
An ODF 1.1 document still would have to be processed as an ODF 1.1
document by an ODF 1.2 application. We do not and can not change the
processing of ODF 1.1 documents by the ODF 1.2 specification.
> look at the Document Processing portion of the proposal separately, after
> deciding if any of it belongs in the conformance section.
>
> 2. With regard to P1.3, I think the statement should be stronger. I think
> that if a conforming consumer does not interpret the semantics of an
> element, attribute, or attribute value, it SHOULD behave as if that were a
> foreign element, attribute, or attribute value (not sure there is such a
> thing as a foreign attribute value though). We should also consider whether
I don't think that we need that, and I'm also not sure if this would
really work.
The ODF specification defines the semantics of the elements it defines.
Whether a consumer that does not support a particular element has to
process the content of that element depends on whether there are child
elements it supports. Which means that the implementors of a consumer of
cause have to decide what action the consumer takes for all elements
that ODF defines, even if they don't support or do not fully support a
particular element. The difference to foreign elements is that they can
make that decision, because the ODF specification tells them what the
elements mean. That is not the case for foreign elements. For this
reason, we need some precise rules there.
> office:process-content could be used in those cases by document producers in
> advising less-capable consumers of an appropriate action.
Again, I don't think that is necessary. Even a less-capable application
has to take some reasonable action for elements it does not support.
What actions this is depends on the purpose of the specification. I
don't think that can be decided by an application that stores a
document, and which does not have any knowledge about the "less-capable"
application.
Furthermore, using the attribute for elements that ODF defines would
only increase the document size, but it would not add any value, because
the information whether it is reasonable to process an element or not
can be found already in the specification.
Best regards
Michael
--
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