W3C home > Mailing lists > Public > www-svg@w3.org > September 2004

Re: sXBL draft comments

From: Chris Lilley <chris@w3.org>
Date: Thu, 2 Sep 2004 17:59:33 +0200
Message-ID: <1273598262.20040902175933@w3.org>
To: "Karandikar, Shailesh" <Shailesh.Karandikar@dendrite.com>
Cc: www-svg@w3.org

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.

 Chris Lilley                    mailto:chris@w3.org
 Chair, W3C SVG Working Group
 Member, W3C Technical Architecture Group
Received on Thursday, 2 September 2004 15:59:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:02 UTC