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] | [Elist Home]

Subject: Re: [office] Processing Instructions


Jason Harrop wrote:
> Should our specification state explicitly how compliant applications are
> to handle processing instructions?

Well, I wouldn't like that... Please see below.

> I would expect that by default, an editing application should preserve
> processing instructions which it does not understand.  (By contrast,
> when I tested OpenOffice (641 or 643) by manually inserting a processing
> instruction in the content and then opening it in OpenOffice, editing
> and saving again, the PI got removed.)

Indeed. The problem is that processing instructions (PI) are, by and 
large, not part of the content but rather of the physical 
representation. And the physical representation of a document is 
something that we can't (and don't really want to) preserve. The same 
applies to e.g. the text encoding, entities, or indentation.

The problem is that preserving 'arbitrary' data is only really possible 
if your internal document model is DOM (or something rather similar). I 
assume DOM would be a fairly natural document model for an XML editor 
(or other XML centric tools). But it's unsuitable for an office application.

What OpenOffice.org does when loading XML files is to translate from the 
XML representation into the internal representation. All content from 
the XML representation has equivalents in the internal one, so the 
conversion is lossless. However, everything not specified in the format 
(e.g. PIs) will (generally) be dropped.

The problem is that PIs can occur just anywhere with any content, so 
it's plainly hard to put the data somewhere. If one has a generix 
documet model (like DOM), it's not much of a problem. If one has a more 
specialized document model (as OpenOffice.org does, and as I'm sure 
virtually any other office application has), that's a major problem. I 
doubt that OOo (or any other office suite) would ever manage to 
completely comply with such a requirement...

Jason, a rather basic question: What were you actually trying to 
achieve? Would other forms of extensibility cover your needs?


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

Powered by eList eXpress LLC