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

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
>>
>
>