[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Your office-comment: Semantics of "loading" (ODF all versions)
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.