Re: sXBL draft comments

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,

<svg xmlns="http://www.w3.org/2000/svg" 
xmlns:xbl="http://www.w3.org/2005/xbl" xmlns:xlink 
="http://www.w3.org/1999/xlink" 
xmlns:foo="http://www.mycompany.com/xmlns/foo" 
xmlns:xf="http://www.w3.org/2002/xforms">
    <xf:model id="myData" schema="FooSchema.xsd">
        <xf:instance src="http://www.mycompany.com/data/dataFile.xml"/>
    <xf:model>
    <xbl:xbl ...>
</svg>
   
Of course, by that same logic, you should be able to do the same with

<svg xmlns="http://www.w3.org/2000/svg" 
xmlns:xbl="http://www.w3.org/2005/xbl" xmlns:xlink 
="http://www.w3.org/1999/xlink" 
xmlns:foo="http://www.mycompany.com/xmlns/foo" 
xmlns:xi="http://www.w3.org/2001/XInclude">
         <xi:include href="http://www.mycompany.com/data/dataFile.xml"/>
        <xbl:xbl ...>
</svg>

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.

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



Chris Lilley wrote:

>On Thursday, September 2, 2004, 4:29:02 PM, Shailesh wrote:
>
>
>
>KS> It would be interesting to know considerations behind not extending
>KS> XForms like bind model where the contents of the bind are 'computed' SVG
>KS> fragments.
>
>XForms uses Xpath to bind the abstract widget to the portion of the
>model that it controls. sXBL uses Xpath (or Selectors or some suset of
>either, not decided yet) to bind a template to a portion of the original
>document that it is the rendering of. So yes, very similar at the
>overview level.
>
>Does that mean you would prefer Xpath over Selectors, btw, or the
>reverse, or no opinion?
>
>KS> Regards
>
>KS> -----Original Message-----
>KS> From: www-svg-request@w3.org [mailto:www-svg-request@w3.org] On Behalf
>KS> Of Chris Lilley
>KS> Sent: Thursday, September 02, 2004 4:44 AM
>KS> To: Cameron McCormack
>KS> Cc: www-svg@w3.org
>KS> Subject: Re: sXBL draft comments
>
>
>KS> On Thursday, September 2, 2004, 5:15:09 AM, Cameron wrote:
>
>
>KS> Hey Cameron,
>
>CM>> Some comments about the sXBL draft.
>
>CM>> 4.2 Processing content elements
>
>CM>> Full XPath makes sense to me.  If you are already going to have
>KS> XPath
>CM>> support from DOM 3 XPath, you may as well use it.  What is a
>KS> "predefined
>CM>> XPath profile"?
>
>CM>> But I guess it's the issue of dependency tracking that is the
>KS> problem.
>CM>> I have done it for full XPath, so it is possible.  (Well I didn't
>KS> handle
>CM>> the following and preceding axes, but who ever uses those. ;))
>
>KS> Hence the 'defined subset' :)
>
>CM>> Regarding sorting, I hadn't really considered it.  I guess it is
>CM>> certainly possible authors will want to sort the elements
>KS> differently.
>CM>> xsl:sort?  How close to XSLT do you want this template to become?
>
>KS> It should draw from it, certainly, if there are established ways of
>KS> doing things.
>
>KS> Since you mention XSLT, its important to note a big difference between
>KS> XSLT and sXBL. In XSLT, its a one-shot, batch-like transform. If any
>KS> changes are made to the result, they have no effect on the source and do
>KS> not cause the transform to re-run; similarly if there are changes to the
>KS> source they do not affect the result and do not cause the transform to
>KS> re-run. Its certainly possible to imagine a continuously looping XSLT
>KS> process triggered by mutation events (at least, for source changes) but
>KS> its hard to iimagine event flow in the result tree continuing
>KS> uniinterrupted in that case.
>
>CM>> It is mentioned with the second proposal for handling content
>KS> elements
>CM>> which match no nodes that it keeps the flattened tree to be a
>KS> superset
>CM>> of the original DOM tree.  Why is that important?
>
>KS> I believe it is for implementation efficiency, but perhaps Ian Hickson
>KS> has more details on why that is seen as desirable. I agree the spec
>KS> should explain the value of keeping it a superset.
>
>CM>>  If there are elements
>CM>> which I don't want to include in the rendering, it seems silly that
>KS> they
>CM>> would have to be there with a display: none.  I vote for proposal 1.
>
>CM>> 6 DOM Interfaces
>
>CM>> Will there be an interface for the xbl:content element as it appears
>KS> in
>CM>> the shadow tree?  Just like the SVGElementInstance interface.
>
>KS> Interesting suggestion, need to think about that one.
>
>CM>> 6.1 The NodeXBL Interface
>
>CM>> The element versions of firstChild, nextSibling etc. are nice.
>KS> It'll
>CM>> save me writing little functions to skip over whitespace and
>KS> comments.
>
>KS> We figured that was the common task and tried to make it easier.
>
>CM>> 6.2 The Event Interface
>
>CM>> If you are worried about modifying Event from DOM Events, why not
>KS> just
>CM>> have a new interface (e.g. ForwardableEvent or something) and have
>KS> all
>CM>> of the events which are generated by SVG implement that interface
>KS> too?
>
>KS> Yes. I think the idea though is that implementatiions of sXBL modify all
>KS> their events so that they have a consistent, enlarged, interface.
>
>CM>> 6.3 The XBLTemplateElement Interface
>
>CM>> getElementById on XBLTemplateElement: good idea. :-)
>
>CM>> About the note mentioning id attributes having to be of type ID, it
>CM>> seems annoying that I would have to write some DTD just to allow my
>CM>> custom elements to have id attributes that work with getElementById.
>CM>> But I don't like DTDs anyway.
>
>KS> Nor do we. Please see
>KS>  http://www.w3.org/2001/tag/doc/xmlIDsemantics-32.html
>KS>  http://www.w3.org/TR/xml-id-req/
>KS>  http://www.w3.org/TR/2004/WD-xml-id-20040407/
>
>
>CM>> More comments later, perhaps!
>
>KS> Look forward to them.
>
>
>
>
>
>
>  
>

Received on Thursday, 2 September 2004 16:55:30 UTC