Date: prev next · Thread: first prev next last
2014 Archives by date, by thread · List index


On 28.11.2014 03:35, Markus Mohrhard wrote:
Hey,

so I was just looking through some of out calc issues and found a 
surprising validation error. According to odfvalidator the following 
snippet is invalid.

<number:number-style style:name="N125P1" style:volatile="true"> 
<loext:text>-</loext:text> <loext:fill-character>
</loext:fill-character> <number:number number:decimal-places="2" 
number:min-integer-digits="1" number:grouping="true"/> <number:text>
SIT </number:text> </number:number-style>


It took me some time to understand why it complains but at least to
my understanding that snippet is valid. odfvalidator seems to strip
the loext entries and leaves the - resulting in the following xml
snippet:

<number:number-style style:name="N125P1" style:volatile="true"> 
-<number:number number:decimal-places="2" 
number:min-integer-digits="1" number:grouping="true"/> <number:text>
SIT </number:text> </number:number-style>

which is of course an invalid xml file. / /Now looking at the ODF 1.2
spec about handling of foreign elements we find the following
paragraph:/

If a foreign element has a <text:h> or <text:p> ancestor element, and
is a child element of an element for which the OpenDocument schema
permits the inclusion of character data, and if the OpenDocument
schema permits the inclusion of character data for all its ancestors
up to the <text:p> or <text:h> element ancestor element, then the
element's content may be interpreted by conforming OpenDocument
consumers, and the document itself shall be valid against the
OpenDocument schema as if the foreign element's start- and end-tags
or its empty- element-tag are removed. For a foreign element that
occurs at another location, conforming consumers should not
interpret the element's content, but may preserve its content.

/ My interpretation of that paragraph that it is valid to include 
character data in foreign elements and that they should be stripped 
similar to the xml element. Is my reading of the spec wrong?

i believe you are correct, and the answer to the odfvalidator's behavior
is likely found in ODF 1.1:

1.5 Document Processing and Conformance
...
Foreign elements may have an office:process-content attribute
attached that has the value true or false. If the attribute's value
is true, or if the attribute does not exist, the element's content
should be processed by conforming applications. Otherwise conforming
applications should not process the element's content, but may only
preserve its content. If the element's content should be processed,
the document itself shall be valid against the OpenDocument schema if
the unknown element is replaced with its content only.

so this changed from ODF 1.1 to ODF 1.2, and in the new version (by
default when office:process-content is missing) only content of foreign
elements that are children of <text:p>/<text:h> should be preserved;
maybe the odfvalidator was never adapted to this change.

i could take a look at doing that if i find some time...


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.