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] ODF 1.2 Single-Level Conformance and Law of UnintendedConsequences


On 21/01/09 11:05 AM, "Dennis E. Hamilton" <dennis.hamilton@acm.org> wrote:


There are many XML-level processing models that might apply, including ad
hoc ones that Michael suggests may be common for ODF implementations (for
performance reasons, I presume).

DN: At the root level, all XML is ingested as a one dimensional stream of bytes.  There are no variations.  This has to happen before any DOM or post secondary handling can be done.  No variances to this are possible as is noted in the SAX documentation.

  For the level at which we are talking in
regard to conformance and foreign elements and attributes, it is about what
might be accepted as additional markup not accounted for in the strict
schema, but related to the strict schema in a particular way.  We are
talking about what the behavior may be, not how it is achieved.

DN: Which is either at the content handler level or post content handler.  At the content handler level, the content handler could be switched on to drop (remove from memory any non-standard ODF elements or content it encounters.  This even includes non-content such as comments <!--fdjslkjk--> (this was a raging holy war about ten years ago).

Since the provision has been in since ODF 1.0, anyone who has foreign
elements and attributes or who encounters them without rejecting the
document has made some sort of provision.  My experience is that these
extensions (and those of unimplemented ODF features) tend to simply be
ignored and, if the document is touched in any way, they disappear from the
saved modification.  See our investigation of style:wrap-dynamic-threshold

DN: That is the key issue IMO.  Should implementers be forced to keep the non-standard content.  What is the current status of this debate?  How may in favor vs. against?

Duane's comment about buzzword is interesting though.

If the XMP is in a separate item of the package, is it accounted for in
manifest.xml?  There are security reasons why a processor that does not
recognize that item may well strip it to avoid perpetuating unknown content
in a document.  There are also matters of prudence in the case of documents
having some significance as records and Easter eggs and other goodies are
frowned upon.  I also believe we do not have a conformance requirement on
what is in a package beyond what is essential to a given document structure,
but I must go look.  (I will be doing that over on OIC TC anyhow.)

DN: I would be interested in seeing this conformance requirement.  If you find it, can you please forward a reference to me.

If the XMP is injected into one of the ODF XML documents, which one?  Is it
made an element or elements in metadata.xml or is it placed in or near the
document root element of content.xml?  This matters for 1.0/1.1 because
there are different provisions for metadata than for content.  For ODF 1.2,
it's not clear to me where the TC is leaning on that one and you might want
to express your preference in the matter.

DN: We have not actually done it to my knowledge, yet we have discussed.  I  am awaiting the outcome of this discussion before making a recommendation.  Having XMP preserved would be important as it then becomes PDF and PDF/A XMP when documents are archived, often the last step of their lifecycle.



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