RE: sXBL draft comments

Slightly off the topic.

XPath seems to be more natural query language over semi-structured data.

For data drive applications, XPath is a natural choice, not CSS.

What is the benefit in evolving/tweaking CSS to meet advanced
requirements if one already has an alternative which is available in
most DOM implementations?

Regards,
Shailesh

-----Original Message-----
From: Anne van Kesteren [mailto:fora@annevankesteren.nl] 
Sent: Friday, September 03, 2004 11:22 AM
To: Kurt Cagle
Cc: Chris Lilley; Karandikar, Shailesh; www-svg@w3.org
Subject: Re: sXBL draft comments

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

XBL is already used in Mozilla and not really as an implementation layer
between SVG and XForms, since those specifications are not (yet)
supported by Mozilla and will probably only be supported through a
plugin mechanism.

I know there is some support for SVG already, but XBL was implemented
before that and is used for form controls and MARQUEE to name some
examples.


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

You forget that sXBL will become XBL which is not SVG specific. So UAs
who might implement XBL might not have support for XPath.


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

I don't see why this is an argument for XPath over 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).

Where is the argument or reason?


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

That problem has been solved[1] and I think that more (a lot more)
people know CSS Selectors than people know XPath.


> Again, this comes from experience dealing with readers and students
> when I teach CSS classes. 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.

XPath has exactly the same.


[1]<http://dean.edwards.name/IE7/>


-- 
  Anne van Kesteren
  <http://annevankesteren.nl/>

Received on Friday, 3 September 2004 15:39:59 UTC