[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [office] Processing Instructions
Jason, 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? Sincerely, Daniel
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC