[OASIS Issue Tracker] Commented: (OFFICE-3465) ODF CD05-1 10.4.4<draw:image> use of <office:binary-data> unimplementable

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ http://tools.oasis-open.org/issues/browse/OFFICE-3465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=21952#action_21952 ] 

Dennis Hamilton commented on OFFICE-3465:
-----------------------------------------

Considering the xlink:href case in isolation:  I agree with Andreas that the situation is uncertain, depending on the nature of the xlink:href:

 1. If the reference is to a fragment of the same XML document, or to a fragment of another XML document, whether or not in the same package, we do not know what transformation to an image might be called for.

 2. I agree that a reference to a subdocument or single package file in the same package will result in an associated manifest:media-type attribute value also being known.  If that is precise enough, it should be usable (but if it is something like application/xml or text/xml, there's more work involved, as there is if the reference is to a fragment of a single package file).

 3. In the case that the reference is to a resource completely external to the ODF document (package or single file), a MIME type may be available either as a file system feature or as part of retrieval (e.g., via HTTP).  But consumers may just have to do the best they can, and it is not clear what can happen when the reference is not resolvable, since there is no cache in the <draw:image> element.  I suppose it is the same problem that happens with an <img> source in HTML.

I think this is a bit like the problem identified in OFFICE-3385 with regard to <text:section> except that here, the consumer is not provided with a cache of the image so that an attempt to derive the image from the separate source can be omitted or fail but there is a fallback.

Here there is no fallback.  So what constraints are there on producers in this case (accepting that circumstances may change by the time the ODF document is consumed).  What are the conditions on consumers, if any?

> ODF CD05-1 10.4.4 <draw:image> use of <office:binary-data> unimplementable
> --------------------------------------------------------------------------
>
>                 Key: OFFICE-3465
>                 URL: http://tools.oasis-open.org/issues/browse/OFFICE-3465
>             Project: OASIS Open Document Format for Office Applications (OpenDocument) TC
>          Issue Type: Bug
>          Components: Graphics, Part 1 (Schema)
>    Affects Versions: ODF 1.2 CD 05
>            Reporter: Dennis Hamilton
>            Assignee: Patrick Durusau
>            Priority: Blocker
>             Fix For: ODF 1.2 CD 06
>
>
> See similar issue OFFICE-3463
> In 10.4.4, the image (however obtained) is apparently parked in the <office:binary-data> and the only allowed attribute on <draw:image> is the <draw:filter-name>.  (There can be no xlink:href and the defaults for the other xlink attributes are apparently not relevant.)
> All that 10.4.5 <office:binary-data> provides base64binary of the image, but we are given no clue what the represented image format is. 
> Although there is a "should" about [SVG] and [PNG] but no indication how to tell what the <office:binary-data> represents (and if this case is relevant to [SVG], but if not, how is the SVG included in the element, or is that not provided for?)
> It is unclear how there is a choice to represent the image any other way than in binary data, unless the alternative is always with xlink:href and it is not permitted to cache the retrieved image in the <draw:image> element (because it would then not be refreshable).
> This is seriously underspecified as well as not being interoperably implementable from the information provided.
> Although ODF 1.1:9.3.2 is not much more specific.  There, the XLink information is described as not necessary when the <office:binary-data> is present, but it is not described as forbidden.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira