W3C home > Mailing lists > Public > www-svg@w3.org > February 2006

Re: [SVGMobile12] Question on handling of <script> with xlink:href and child nodes

From: Robin Berjon <robin.berjon@expway.fr>
Date: Thu, 16 Feb 2006 22:27:06 +0100
Message-Id: <88901C60-F7C6-4C0D-B371-AC3413A040BB@expway.fr>
Cc: www-svg@w3.org
To: <doug.schepers@vectoreal.com>

n Feb 16, 2006, at 21:58, Doug Schepers wrote:
> Very good examples, Ian, and I suspect more XML scripting languages  
> are on
> the way. My only question is whether these would need to be  
> contained within
> a script block, or only properly namespaced (and accessed in a UA that
> implements them)? I would be happy to raise this as a topic for  
> discussion
> with the SVG WG, if the public consensus is that they need to be  
> (or can be)
> executable children of a script element.

I don't think we care about whether existing W3C "scripting"  
languages might go into script blocks, just that it may be done. We  
could go on forever discussing whether REX is a scripting language or  
not (it's not in my book, but I don't think we want the SVG WG to  
have to come up with a decision on what constitutes a scripting  
language  see the TAG thread on the principle of least power for  
that), and likewise for XForms Actions. The fact is that such things  
may exist is sufficient to require being dealt with. We had a partial  
resolution of this problem at the Sydney f2f, but it needs a little  
more (or less).

The problem that's raised here is that we're trying to define  
behaviour for all possible languages, and we don't know them all so  
we're in fuzzy-land. Some might not have any real XML in them (say,  
only in strings). Some might have some bits of XML (say E4X). Others  
yet may be all XML. The fact of the matter is that there's a context  
switch, and the conformance of everything contained within the script  
element MUST be defined by something other than the SVG specification.

Here's a strawman:

  - for scripting languages that do not match an XML media type, pass  
the textContent. If people do stuff like alert("<bar>foo</bar>") they  
may get unexpected results, but if they're using a text based syntax  
in the first place they should be using CDATA sections.  
Alternatively, in order to perhaps help authors be less surprised  
perhaps that any recognised markup in the script should cause an  
error (but I'd rather not). This includes E4X, for which something  
getting a string (if the user used CDATA) and sometimes a DOM would  
incur a greater implementation cost than this scheme.
  - for scripting languages that match an XML media type (and are  
therefore purely XML based), pass them the DOM (conceptually, it  
needn't be implemented that way)

Thoughts?

-- 
Robin Berjon
    Senior Research Scientist
    Expway, http://expway.com/
Received on Thursday, 16 February 2006 21:27:04 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 5 February 2014 07:14:53 UTC