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

David Janes -- BlogMatrix davidjanes at blogmatrix.com
Thu Apr 6 04:49:23 PDT 2006

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 

Regards, etc...

[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

More information about the microformats-discuss mailing list