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

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
>