RE: sXBL draft comments

XPath would be definitely preferable over selectors, either as a subset
or full [E.g. XQuery path syntax]. I also believe that CSS needs to be
'xmlized' for more flexibility...but perhaps it's a controversial topic.

For bindings, as you remarked, they are very similar. In my opinion,
XForms processing model could be naturally extended to include sXBL
processing.

Example: Something like
<svg>
 <defs>
 <model>
     <instance>
	  <Car color="red">
	     <Price>100</Price>
	     <Specs>
	      <Length/>
	      <Height/>
	     </Specs>
	   </Car>
     </instance>
	
	<!-- Nodeset is specified by the custom element. 
 	     @match allows potential for further enhancements
      -->
     <bind match="TheCar">
       ...
	  <rect width="{Spec/Length + 10}" height="{Spec/Height + 10}"/>
	  <path fill-color="{@red}"/>
	  <text y="{Spec/Height + 20}">{get-price(@Color)}</text>

       ...
     </bind>
     <bind>
	 <!-- current sXBL bindings-->
     </bind> 
   </model>
 </defs>
 <g>
    <!-- sXBL binding provides the instance context ->
    <TheCar ref="/Car"/>
 </g>
</svg>
Etc.

-----Original Message-----
From: Chris Lilley [mailto:chris@w3.org] 
Sent: Thursday, September 02, 2004 12:00 PM
To: Karandikar, Shailesh
Cc: www-svg@w3.org
Subject: Re: sXBL draft comments

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 17:53:34 UTC