[uf-discuss] Live Clipboard and uF escaping (was Fwd: 0.91 Spec comment: escaped markup is harmful)

[David Janes -- BlogMatrix]

Weird, I had just responded saying:

1. microformats are well-defined, XML, and easy to use and thus nothing 
is gained from "pure" XML serialization
2. content payload definition is well defined in Atom [1/2], so they 
should consider using that.

I think it takes time for people to get their heads around uFs, so they 
tend to look for the complicated solution when the easier one looks just 
fine.

Regards, etc...
David

[1] 
http://www.atomenabled.org/developers/syndication/atom-format-spec.php#element.content
[2] http://tinyurl.com/9vr68#element.content

Danny Ayers wrote:
> Dear uFers,
> 
> The post below is from the MS Live Clipboard list,
> 
> http://discuss.microsoft.com/archives/live-clip.html
> 
> in relation to:
> 
> http://spaces.msn.com/editorial/rayozzie/demo/liveclip/specification/v091.html
> 
> I'm not sure I understand why Matt suggests XML data might have to be
> delivered as both XML and escaped as well, but he gets into
> browser/DOM territory, a place presumably well-known around this list
> - thoughts appreciated.
> 
> ---------- Forwarded message ----------
> From: Matt Augustine <matta at microsoft.com>
> Date: Apr 6, 2006 5:23 AM
> Subject: Re: 0.91 Spec comment: escaped markup is harmful
> To: LIVE-CLIP at discuss.microsoft.com
> 
> 
> Thanks for all the information.  Escaping only non-XML data formats and
> leaving XML data formats as part of the Live Clipboard document seems
> like a reasonable compromise, but I have a few reservations:
> 
> Since the items in the LiveClipboardContent object might contain either
> XML or escaped, non-XML data, we would most likely have to add a second
> property, named something like xmlData, to hold an XML node in addition
> to the existing data property.  Applications would have to know which
> property to use based on the contenttype of the format.
> 
> In the microformat case, treating the data as a string rather than as
> parsed XML makes it easy to display the data by setting it as the value
> of the innerHTML property of an element on the page.  In order to avoid
> forcing applications that use this technique to first serialize the
> xmlData, we would probably want to always provide this serialized data
> in the existing item data property.  If there is a way to directly add
> the parsed XHTML of the microformat into an HTML element we could avoid
> this, but as far as I know this isn't possible.
> 
> IE6 provides an easy way to get the serialized string value of all the
> xml content of a particular node via the "xml" property.  I'm not aware
> of a similar property when using the DOMParser in Mozilla or other
> browsers.  Is there an easy way to get access to this serialized data in
> order to satisfy the previous requirement?
> 
> As for David's comments about the ugly XML parsing / serialization code,
> we tried to contain all of that error-prone stuff within our script to
> make interfacing with Live Clipboard data as simple as possible for the
> developer and to make sure the emitted XML put on the clipboard is
> compliant with the spec.  We're certainly open to alternative light
> weight implementations of the control though, as long as they are
> compatible with the clipboard XML format as specified and present the
> same user experience for copy/paste.
> 
> Thanks,
> 
> Matt Augustine
> Software Design Engineer
> CTO Concept Development Team
> Microsoft Corporation
>