Re: sXBL draft comments

Hi Kurt,

Kurt Cagle wrote:
> A couple of comments on sXBL from this end.
> 
> 1) I 'm envisioning this in some kind of process where the SVG is 
> generated from external XML data. As such, it would seem reasonable to 
> me to have some way of externally referencing a data-source, rather than 
> requiring that the data be embedded within an svg container directly. 
> For instance,
> (...)
>        <xf:instance src="http://www.mycompany.com/data/dataFile.xml"/>
> (...)
>         <xi:include href="http://www.mycompany.com/data/dataFile.xml"/>
> (...)
> However, neither mechanism is, to my awareness, currently supported 
> within SVG, and without it I see a necessity of either DOM or XSLT 
> manipulation to do anything beyond the most trivial applications. 
> Moreover, these would obviously need to fire mutation events when 
> external documents are loaded.

I agree that the feature you want is desirable, but having used RCC 
quite extensively before it turned into sXBL, and my own hacks to get 
similar effects previously, I disagree that without external references 
it is impossible to do anything beyond "the most trivial applications". 
In effect, a lot can be done without this feature.

There are quite a few potential issues with applying sXBL to external 
documents, relating to problems such as needing an <svg> context, 
dealing with event propagation, defining what happens when the same 
external document is pointed to more than once from the same SVG 
document, whether it behaves as a reference or an inclusion, at which 
moment in the processing model is it processed, etc.

I'm not saying that these issues are unsolvable, just that solving them 
is work especially if the solution is to be generic enough. As such, it 
is better offloaded to a later version when we will have much better 
experience with what people have actually been doing.

The getURL, parseXML, insertChild sequence that is needed to do this in 
its simplest incarnation is trivial for users to implement. When a 
sufficient number of users have done this it should be obvious which 
options and processing model is most desirable.


> 2) I'm going to put my two cents worth in for binding with XPath, for 
> several reasons -
>    a) One of the reasons for the XBL specification in the first place 
> was to provide the implementation layer between SVG and XForms, and 
> XForms supports XPath. Without the support in XBL (where I feel it most 
> belongs) much of the more sophisticated actions inherent within XForms 
> require become problematic, if not impossible.

I prefer XPath over CSS Selectors too but I don't see how XPath is 
required to bind to XForms, so long as one has access to an XPath API.

>     b) Most current "complete" SVG implementations exist in an 
> environment when such XPath support already exists (Java, COM, .NET, 
> Rhino, Mozilla Seamonkey, libXML, etc.) and as such the necessity for 
> vendors to build their own XPath implementations is somewhat reduced.

Again, agreed, but the same argument pretty much goes for CSS Selectors.

>     c)  XPath significantly reduces the amount of imperative code needed 
> within applications (I'm thinking specifically of the <xbl:content> tag 
> here), which I see as one of the major rationales for SVG over a 
> platform dependent implementation such as GDI. Moreover, even in that 
> imperative code, the preferred node selection capability would probably 
> be to use XPath rather than go through the pain of trying to navigate 
> the tree manually. I'd far rather see
>       <xbl:content src="bar[position() % 2 = 0]"/>
> then a complex block of procedural code to do the same thing - select 
> every even child "bar" element.

XPath can select more granularly than CSS, but the above can be done by 
CSS too.

>     d) I have often used the complexity of XPath as one of the reasons 
> for not incorporating it in SVG. However, it has been my experience in 
> teaching classes on SVG and dealing with readers as a technical writer 
> that if they are sufficiently savvy to master rudimentary SVG skills, 
> they can easily master rudimentary XPath.

Certainly, especially as XPath is, well, not complex at all :) But 
again, that doesn't really tilt the balance away from CSS.

>      e) I would recommend that you mandate the full XPath solution for 
> SVG Basic, and the reduced set XPath solution for SVG Tiny. I understand 
> the memory requirements that SVGT targets have, making it difficult to 
> implement the full set, but a simnple tree walker parser can readily be 
> implemented (and indeed probably already exists).

At this point in time there is no SVG Basic anymore -- the WG might pick 
it up again later but when we asked around there was no interest 
whatsoever. Also, sXBL won't be available in Tiny 1.2 so it doesn't 
apply. Tiny 1.2 might choose to support the application APIs (this is in 
fact quite likely on some platforms) in which case it could support the 
XPath API. If so, I would expect it to use something like the EMMA 
subset of XPath, which is trivial to implement.

>      f) A quick argument against using CSS Selectors - The CSS selector 
> model beyond the simplest matching mechanisms is generally not well 
> understood by more than a small proportion of the web development 
> universe, in  great part because the browser with the largest market 
> share does not support that functionality properly. Again, this comes 
> from experience dealing with readers and students when I teach CSS 
> classes.

Yes, but then is the part of the community that understands XPath beyond 
the simplest matching mechanisms larger?

> Moreover, the CSS model requires the use of certain reserved 
> characters (the ">" greater-than character)  to facilitate its operation 
> for the more sophisticated operations that will cause compilation errors 
> with many XML parsers.

That's a non-argument, XPath also has > and < and they have to be escaped.

-- 
Robin Berjon

Received on Friday, 3 September 2004 11:14:45 UTC