RE: Your office-comment: Semantics of "loading" (ODF all versions)

["Alex Brown" <alexb@griffinbrown.co.uk>]

Dennis hi! 

> Concerning this question and your earlier observation about 
> scripts in ODF Documents 
>
(http://lists.oasis-open.org/archives/office-comment/200903/msg00001.htm
l),
> I don't think this is fixable.
> 
> It seems to me that saying anything about what a script does 
> and when it does it, except for UI event listening, is pretty 
> meaningless in the ODF specifications and it is probably 
> really all just implementation-defined in the current texts.  
> 
> Considering that there is no specified Document Object Model 
> for use among scripts, and no differentiation between 
> manipulation in an instantiated DOM versus the persisted ODF 
> Document representation, timing and restrictions on timing 
> are simply non-actionable as normative statements.

Right, so the stuff about "loading" and "loaded" should really by
removed from the ODF spec, as it cannot be meaningfully standardised.
 
> I suppose one could presume an XML DOM based on the 
> <office:document> (the single XML document representation of 
> an ODF document) that even packages
> might correspond to.   

Possibly, though DOM is perhaps the most horrible of the XML tree APIs.

(I am presenting a paper at XML Prague which will air a suggestion about
cursor-based APIs for in-memory representation of office documents. But
this stuff is still fairly "out there".)
 
> Unfortunately, the mapping is incomplete (there being 
> features of packages that have no <office:document> 
> counterpart), some implementers regret <office:document> is 
> in the specification at all (even though it is the closest we 
> have to something that has a leverageable DOM), and the 
> mapping cannot be carried out literally because of problems 
> with URIs that refer to (fragments of) package components and 
> prospects of collisions of ID-valued attributes from the 
> separate XML document parts. 

Could not the package XMLs be viewed as a collection of trees? (wasn't
this a "hyperdocument" in HyTime terms ?)
 
> Absent an ODF document model (as opposed to the XML infoset 
> that applies only at the level of individual parts), it seems 
> to me that the safest thing to do in ODF 1.2 is to declare 
> scripts and similar oddities of the specification to be (1) 
> implementation-determined and (2) confined to extended ODF 
> documents.  

I certainly agree that if scripts stay unspecified, they should be
placed very firmly in the "extended conformance" box. For *users*
wanting more certainty about interoperable documents that would be an
obvious benefit. I suspect you might find though that this was not a
*vendor*-palatable move, as it would mean than OpenOffice.org would have
to default into having "extended conformance" for scriped files, and
that wasn't the plan at all! (Of course MS Office would too, assuming it
will be possible to use macros with ODF document in MS Office.)
 
> Since this is clearly a broken extension point in the 
> specification, this would also be a good place to attempt 
> complete removal for future return when we actually have 
> something useful to say here.  I am not making book on any of 
> those prospects.
> 
> That's my top-of-head thinking, for what it's worth.  I can 
> imagine this gap being filled by an effort comparable to the 
> OpenFormula work, or carried out by a rump consortium (e.g., 
> like a Sun-Microsoft-IBM submission to W3C) that works up an 
> implementable, demonstrable specification and proposes it for 
> future incorporation.

SC34/WG1 has "APIs for document processing" as one of its areas of
responsibility, and there has been some talk of a universal API for
office documents (both 26300 & 29500). However, we are currently
under-resourced for such an effort. If the ODF TC isn't interested in
doing this for 1.2, maybe WG1 should be pressing harder to start
something in this space ...

> I suppose this might better be a blog point-counterpoint than here.  
> 
> Any further thoughts on this, Alex?

What I'd really like to see is for "live" office documents to be
processable with standard APIs (Xpath/Xquery), rather than having to
serialize/process/de-serialise all the time. OOXML-Next and ODF-Next
could usefully point in that direction.
 
>  - Dennis
> 
> This message is my personal observation and any similarity to 
> an official position of the ODF TC or of OASIS is purely 
> coincidental.  Were there such an official position, there'd 
> be provision of a link to the official minutes or other 
> approved document where the official position is expressed.

Understood!

- Alex.