W3C home > Mailing lists > Public > public-html-xml@w3.org > January 2011

Re: What problem is this task force trying to solve and why?

From: Kurt Cagle <kurt.cagle@gmail.com>
Date: Tue, 4 Jan 2011 17:31:34 -0500
Message-ID: <AANLkTi=tbGe0BzDBeBBpD8rRuVjhRyMbtXY6GLbOzS1a@mail.gmail.com>
To: John Cowan <cowan@mercury.ccil.org>
Cc: Henri Sivonen <hsivonen@iki.fi>, public-html-xml@w3.org
Oops - s/impluting/imputing/

Kurt Cagle
XML Architect
*Lockheed / US National Archives ERA Project*

On Tue, Jan 4, 2011 at 5:30 PM, Kurt Cagle <kurt.cagle@gmail.com> wrote:

> I LIKE <scritchifchisted> myself!
> Difference between <script> and <foreignContent> - script implies a
> processor will take the content and instantiate it in some manner:
> <script type="text/javascript">
> not only identifies the content as being foreign content, but also parses
> it with the JavaScript parser and instantiates it; it places the onus of the
> operation on the browser to do something with the content. I would consider
> <script type="application/xml" id="foo"></script> and <xml id="foo"></xml>
> to be effectively the same in that they would instantiate the XML as a DOM
> and bind that to the script element. If that's the existing behavior, that's
> great, but I didn't believe it was.
> <foreignContent> on the other hand, is a completely semantically neutral
> element - it does not attempt to parse the content in any way, but simply
> serves as a mechanism to hold that content in a consistent way within the
> page for referencing by another process. I believe this is where SVG got it
> wrong - the foreignObject there attempts to parse HTML content dynamically,
> which to me would seem to be the providence of <script> instead. RDF
> content, on the other hand, would be a good candidate for foreignContent,
> but SVG has the <metadata> element there instead, which struck me as
> impluting too much semantics (and expectations of semantics) into the SVG
> body.
> With such a semantically neutral tag, this also gets around the issue of
> requiring that the HTML5 processor be required to parse the XML at
> processing time, which means that if you have namespaces or other entities
> contained within XML within the <foreignContent> element, the HTML5 parser
> would not have to parse those namespaces directly. There would be nothing
> stopping you from binding the foreignContent> element via XBL:
> <foreignContent role="docbook">
>       <docbook>...</docbook>
> </foreignContent>
> would be neutral (wouldn't appear) within evaluation of the web page
> itself, but a binding:
> foreignContent (role="docbook")
> {binding:url("myDocBookRenderer.xbl");display:block;width:6in;height:8in;}
> could in fact display it just fine by parsing the inner content of the
> foreignContent as text with an XML parser and then doing the appropriate
> transformations on that content.
> Kurt Cagle
> XML Architect
> *Lockheed / US National Archives ERA Project*
> On Tue, Jan 4, 2011 at 4:40 PM, John Cowan <cowan@mercury.ccil.org> wrote:
>> Kurt Cagle scripsit:
>> > One other possibility that comes to mind is simply to create a
>> > <foreignContent> element in HTML5. SVG has a similar element (usually
>> > for holding HTML, oddly enough). This would simply tell the processor
>> > to not display the content in question, not to parse it, not to do
>> > anything with it.
>> That's what "script" does, and I see no reason to duplicate it.
>> On the other hand, having an <xml> element which says that everything up
>> to the matching </xml> is well-formed XML (without prologue or epilogue)
>> and should be incorporated into the DOM seems a good idea to me.  If there
>> are legacy concerns with <xml>, use <well-structured-extension> or for
>> that matter <scritchifchisted> instead.
>> --
>> We are lost, lost.  No name, no business, no Precious, nothing.  Only
>> empty.
>> Only hungry: yes, we are hungry.  A few little fishes, nassty bony little
>> fishes, for a poor creature, and they say death.  So wise they are; so
>> just,
>> so very just.  --Gollum        cowan@ccil.org  http://ccil.org/~cowan
Received on Tuesday, 4 January 2011 22:32:32 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:58:27 UTC