Re: [office] Office document fragment identifier

[Michael Stahl <mstahl@redhat.com>]

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