Re: [ietf-types] Request for review of standards tree registration request for OpenXPS

[Brian Clubb <[e-mail]>]

Paul,

While the OpenXPS package contains XML, the document itself requires the hierarchical tree structure of pages and resources to be functional.  It is intended that only a complete OpenXPS document would ever be posted to the clipboard.  Posting a fragment of an OpenXPS file to the clipboard would not be a useful scenario in the same way that I understand it would work in MathML or SVG.  The resource tree in OpenXPS is integral to its functionality.

For example, copying the XML for a fixed page out of one file onto the clipboard would not take into account the image and font resources which are stored in other locations in the OpenXPS file.  Furthermore, re-integrating that page markup into the structure of another OpenXPS file would be extraordinarily complex.  If one were to wish to copy pages from one OpenXPS file to another, they would need to create a complete OpenXPS package containing just the required pages plus the required resources from the original OpenXPS package then post the new OpenXPS file to the clipboard.  The consuming application would then be able to access that file and its resources reliably and logically insert the pages and resources into their OpenXPS document package as needed.

If an application such as an XPS Viewer were to allow selecting and copying of the text or image elements displayed on the screen, that data would be placed on the clipboard as text or whatever image format the application chooses to provide, but posting the markup for the selection to the clipboard would not provide the relevant resource data and hierarchy and would thus be unusable as OpenXPS at that point.

I believe, then, that it is correct to say that the clipboard format would always be a complete OpenXPS file with .oxps extension.  It is the only format for the clipboard that would provide the required interoperability between OpenXPS-consuming applications.

Thanks!
Brian


-----Original Message-----
From: Paul Libbrecht [mailto:[e-mail]] 
Sent: Wednesday, January 26, 2011 1:45 PM
To: Brian Clubb
Cc: [e-mail]
Subject: Re: [ietf-types] Request for review of standards tree registration request for OpenXPS




Le 26 janv. 2011 à 00:33, Brian Clubb a écrit :

> For your feedback on changing certain responses to lower-case, I will do so in my final submission.  I appreciate your attention to detail on this matter.

good.

> For the comment on encoding, per rfc4288 section 4.8, the possible responses here are 7bit, 8bit, binary, and framed.  This response appears to be correct for ZIP archives and matches a previous registration for Microsoft's version of XPS (http://www.iana.org/assignments/media-types/application/vnd.ms-xpsdocument).  If there is some other consideration here, I am happy to make a note of it elsewhere in the template as needed.

I am too little of an expert here.

> As to the clipboard request, I checked the clipboard values on both Windows OS and Mac OS.  For Windows, the clipboard contains the full file path to the copied .oxps file as a string.  On a Mac OS (10.x), the filename plus extension is provided on the clipboard as "text / items".  Since these conventions may change over time based on the OS independent of any changes to OpenXPS, I am not certain this would be useful as part of the template.

I'm afraid you misunderstood my request.
The objective was to specify within this registration names that would denote one of the alternate representations of a fragment copied to clipboard to be encoded in OpenXPS. This would allow fragments to be stored by one application in the clipboard at the copy command and to be read from the clipboard at the paste command.

Lack of specifying this in the past for MathML has lead to a multitude of names, mostly killing interoperability, with the last suggest being... put the XML in the text flavor (which is clearly wrong for, say, a mail).

(see the MathML and SVG registrations for examples)

paul