Re: sXBL draft comments

On Thu, 2 Sep 2004, Kurt Cagle wrote:
> 
> 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.

That's just one of many use cases for XBL. Web component technologies 
(HTCs, Mozilla XBL) existed long before XForms, and the primary use case 
for them is creating new HTML form controls, in an environment with no 
XPath support, but strong (CSS) Selectors support.


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

Could you give examples of this? I can't really think of any cases in 
XForms where you would use XBL's <content> element to implement something 
which, in XForms, is implemented using XPath.


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

However, XBL itself is targetted at more than just the SVG world, 
including environments where XPath is not available, and where XPath 
support has been deemed too resource-intensive.


>     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 includes="bar[position() % 2 = 0]"/>
> then a complex block of procedural code to do the same thing - select every
> even child "bar" element.

Selectors could do this even easier:

   <xbl:content includes="bar:nth-child(even)"/>


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

XBL is also aimed at HTML authors who may not be sufficiently savvy to 
master rudimentary SVG skills. :-)


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

CSS Selectors has the advantage in such environments that it has been 
specifically designed to be fast 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.

Of course, the same could be said for 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.

Such characters are trivially escaped, and are also used in XPath.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Saturday, 4 September 2004 10:43:52 UTC