OASIS Open Document Format for Office Applications (OpenDocument) TC

  • 1.  Office document fragment identifier

    Posted 03-04-2013 16:30
    Taking the xml:id discussion as an opportunity to ask for the interest of implementations for fragment identifiers for office documents: https://wiki.oasis-open.org/office/Change_Proposal_for_ODF_1.2_using_URL_fragment_identifiers_for_ODF_media_types Think of referencing to a certain presentation slide via a number // Referring to slide 42 http://example.org/doc.odp#42 // Referring to a cell-range of (the first) spreadsheet http://example.org/doc.ods#B4:C7 ... Loading and opening one of the above URLs would result into opening the document with viewing the selected part (perhaps even annotating it for the cell range example). The advantage over xml:id, there is no need, that the creator has added an ID at the content the user desires to point out. The selection is in general a selection of document pieces, we call component in the Collaboration SC. Might be an interesting side product and especially interesting for web based ODF applications. Additional information: https://lists.oasis-open.org/archives/office/200812/msg00036.html Best Regards, Svante


  • 2.  RE: [office] Office document fragment identifier

    Posted 03-04-2013 17:15
    If by web-based you mean that a browser understands that the fragment part is dealt with on the server side, this will be difficult. In many cases, the fragment is processed on the returned document, and it would take a MIME-type-based browser plug-in to handle this (and the entire document would be returned over the wire). I think the usual way to have servers handle this reliably is to do it with the query part (e.g., ?page=42) and have the server deliver HTML[5] by default, not anything like ODF. I think there is a lot more that needs to be specified to achieve an interoperable protocol for reference to parts/places in documents using a custom URI fragment syntax. One consideration has to do with assumption that xml:id values (as in content.xml?id1) be known to an user composing such an URL. I suspect that it would be more desirable to always use document-level concepts (slides, sheets, headings, table names, cell addresses [not explicit in the ODF XML], bookmarks, etc.) that are commonly user visible and can even be specified by users. It is not clear to me why this needs to be internal to the ODF specification. I can see it as an useful inspiration for a supplemental protocol definition on referencing parts of ODF documents in HTTP. The handling of clip-board conventions for interoperable copy-paste would be another one. How xlink:href attribute values relying on such URL interpretations would be handled within an ODF document is an interesting supplemental case as well, since it is probably not HTML that one wants back. In the Open Package Conventions used for OOXML this is handled by a separate URI scheme. It would be nice if that weren't necessary. Perhaps content negotiation comes into it in the case of HTTP requests from within an ODF consumer (i.e., asking for a clip-board-like response rather than an HTML response). - Dennis PS: What is the date of this proposal?
    Original Message


  • 3.  Re: [office] Office document fragment identifier

    Posted 03-04-2013 19:46
    On Monday 04 March 2013 18:15:24 PM Dennis E. Hamilton wrote: > If by web-based you mean that a browser understands that the fragment part is dealt with on the server side, this will be difficult. In many cases, the fragment is processed on the returned document, and it would take a MIME-type-based browser plug-in to handle this (and the entire document would be returned over the wire). I think the usual way to have servers handle this reliably is to do it with the query part (e.g., ?page=42) and have the server deliver HTML[5] by default, not anything like ODF. An html5 application could also handle an ODF specific fragment identifier fine. The URL of which such an identifier would be a part would, however, not be listed in the location bar of the browser but passed to the HTML5 application via other means, perhaps stemming from a link in an HTML5 email reader. > > I think there is a lot more that needs to be specified to achieve an interoperable protocol for reference to parts/places in documents using a custom URI fragment syntax. One consideration has to do with assumption that xml:id values (as in content.xml?id1) be known to an user composing such an URL. I suspect that it would be more desirable to always use document-level concepts (slides, sheets, headings, table names, cell addresses [not explicit in the ODF XML], bookmarks, etc.) that are commonly user visible and can even be specified by users. > > It is not clear to me why this needs to be internal to the ODF specification. Agreed: starting with informal support in number of implementations would be a good start for this. Cheers, Jos


  • 4.  Re: [office] Office document fragment identifier

    Posted 03-12-2013 19:26
    On 04/03/13 17:30, Svante Schubert wrote: > Taking the xml:id discussion as an opportunity to ask for the interest > of implementations for fragment identifiers for office documents: > https://wiki.oasis-open.org/office/Change_Proposal_for_ODF_1.2_using_URL_fragment_identifiers_for_ODF_media_types > > Think of referencing to a certain presentation slide via a number > > // Referring to slide 42 > http://example.org/doc.odp#42 > > // Referring to a cell-range of (the first) spreadsheet > http://example.org/doc.ods#B4:C7 > > ... > > Loading and opening one of the above URLs would result into opening the > document with viewing the selected part (perhaps even annotating it for > the cell range example). > The advantage over xml:id, there is no need, that the creator has added > an ID at the content the user desires to point out. at what level (which part of the spec) do you want to add these fragment identifiers - at the ODF package level or at the ODF document content level? i think it is useful to have some convenient "shorthand" fragments like your page number or slide number or cell range examples; these would be at the document content level. for xml:ids it would make sense to me to be able to refer to elements of the top-level document only; there is theoretically the possibility of the same xml:id being used in both styles.xml and content.xml, but we can just define the content.xml to take priority and this should be good enough. (also you probably can't actually jump to an xml:id that is inside a header in a page style that is not actually used in the document, but who cares...) what i don't like however is the idea of encoding a "path into the package" in the fragment identifier. it would be much better to have a proper URI scheme that allows doing that, because with an URI scheme it can be used as a base URI to resolve relative URIs as described in RFC 3986, which is not possible with fragment identifiers. there is already a "jar:" URI that is actually implemented in some applications (e.g. Java stuff and Mozilla), but not standardized formally AFAIK. there is also some OOXML package URI scheme that is formally standardized but unfortunately defined to be used only with OOXML packages (or whatever the proper term is). then there are vendor specific URI schemes for the same thing such as "vnd.sun.star.pkg:" in OpenOffice.org and derivatives. what is missing is a generic URI scheme to refer to contents of generic ZIP files that is actually formally standardized. regards, michael -- Michael Stahl Software Engineer Platform Engineering - Desktop Team Red Hat Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com


Related Content