RE: Why Binding Scripting in Style Layer Conflates Semantics

Hello all,

I'd like to comment on this interesting discussion, with a couple of points
that I feel are missing here--one is binding to data types, and the other is
where all this fits in with object programming. I've also provided some
links to blog entries of mine on this subject, which might be relevant to
people interested in the XBL and Semantic Web aspects of this discussion.
And a couple of the blog entries discuss--and show some screenshots
of--widgets being created by combining other widgets; in the examples a
widget is created that combines an image from Flickr with an SVG analogue
clock widget that shows the time that the picture was taken. This widget is
used multiple times to create another widget--a 'Flickr-strip' of ten images
that have been tagged with a specified keyword.



OBJECTS

On OO first. The problem with the 'traditional' approach is that it operates
in terms of pre-defined objects--XAML is in this category. So we tend to
define things like 'map widgets' that have 'map interfaces' and then use
them in our pages or applications. Using a <mapselect /> tag is a good
illustration of thinking in this mind-set.

However, the years of research that went into XForms (and is still going in)
has shown that to get accessible, cross-platform applications you should
abstract out the task, not the tool. This is along the lines of those in
this discussion who favour saying <select />, rather than <mapselect />. In
this approach the 'map' is relegated to being just one particular widget
that can be used to help the user choose a county, always assuming that the
device they are using supports such a thing. But the <select /> is the
primary thing--the author of the form needs a 'country' to be chosen before
the form can be fully processed, and from the standpoint of this form's
logic, it matters little how that country value is acquired.

(Lachlan described this very well in his last post, and though Shelby is
making some interesting points, I feel it is *he* that has not read
Lachlan's post closely enough, not the other way round.)

So, to reiterate, the only interfaces that are of interest are the 'select
an item from a list' interfaces. What that is a list of, how it is
generated, whether it speaks, shows a map or waves a flag is irrelevant. And
most crucially is irrelevant to the semantics.

Note that this does not mean that the widget that does the mapping needs to
'inherit' from <select />; a far more flexible technique is to just code up
the map selector widget in the way that you want it to work, and then 'bind'
it to the <select /> when it is needed.

An interesting way of doing this--which is where the power of XBL comes
in--is to 'decorate' the <select /> object at run-time with the properties
and methods of the 'mapselect' object. (Or to decorate it with a set of
interfaces that allow it to interact with a 'mapselect' object, if you are
using someone else's widget.) And it is this dynamic, run-time binding that
is actually needed to realise the Semantic Web! Much has been written over
the years about how great the SW could be, and the implication is that if
only the world would tag stuff, we could get the SW moving. But actually the
key problem is the immaturity of the UI and the issue of dynamic, run-time,
representation of data has never really been addressed. You can write
application generators that do it, but you need to know in advance what
you're getting. Or applications like Haystacks and Piggy Bank can handle a
small set of special cases, without being completely dynamic. But if you
combine XBL with XForms, you really can solve this problem.



BINDING TO DATATYPES

Just in case this point isn't clear, I'll give an illustration--we've been
discussing a map, so let's stick with that. At one end of the spectrum you
have the hard-coded, Java-XAML-C++-like approach, that says, "at this point
in my form/application, place a map". If you want to change it to something
else (a list of cities instead of countries, for example) you either
re-compile, or you edit your XAML, but either way you have to change the
*application*.

In the middle of the spectrum you have another approach, that of using
<select type="select-a-country" />. This is better, for the reasons some on
this list are saying, in that the thing that does the map is moved
elsewhere, and the 'binding' is established at the CSS level. But as it
happens you have still said "at this point in my form/application, place a
map". You've done it in a nicer, more abstract way, but you've still in
effect changed your application. Your mark-up just looks something like
this, instead: <select type="select-a-city" />

Continuing along the spectrum you have the XForms approach:

  <xf:select1 ref="location">
    <xf:label>Choose:</xf:label>
    <xf:item>...</xf:item>
  </xf:select1>

With this mark-up we have in a way gone full circle; the mark-up says
*nothing* about maps, saying simply that we want the user to enter a value
--instead, in our binding layer we say that "for all xf:select1 elements
that are bound to nodes of type 'country', use a map widget". In the same
binding rules we would also say "for all xf:select1 elements that are bound
to nodes of type 'city' use a city selector widget". Unlike our previous
ways of doing this, where we changed our application, both rules co-exist.
And crucially, our form doesn't need to change...all we need to do is change
the underlying data type.

This may not seem such a big difference to the previous two ways of doing
things, until you think about the way distributed nature of information--I
may receive information from some source and not have any control over the
type of the data, and it may even change from one day to the next. Your FoaF
file may have some data that is of type 'country', and some holiday data may
have data of type 'city', but with dynamic, run-time binding on data types
it's no problem.

This explodes the possibilities enormously, and cracks the elusive Semantic
Web problem. Now we can have a form with three country selections on, and
get three maps...or five, or one. It can have maps and city
selectors...thermometers, clocks, maps with clocks on, maps with
thermometers and clocks on, pictures of people with maps with thermometers
and clocks on...the possibilities are endless. The key is that we are no
longer using the old-style programming paradigm of "put a map here", but
instead saying "at this point I want the user to be able to input a value,
but how they input the value depends on what the type of the data is".

One important aspect of this is that we have redefined the problem to be one
of expressing the *bindings*, and that's a nice problem to have. It is
trivial, for example, to allow the *user* to choose their own set of
widgets, or a set from the company intranet, or their portal provided, or
whatever. Then, whenever a form says that a country needs to be entered, the
user could use their *own* country selection list, their own maps, their
company's maps, their own saved list of countries...or whatever.



SCREENSHOTS

Anyway, I've written on these subjects a few times, and if anyone is
interested I have quite a few screenshots on my blog of this kind of thing
in action in our software. (Our software is the formsPlayer XForms
processor, and the Sidewinder Web Applications Viewer.) The most recent
screenshots and discussion are here:

  <http://internet-apps.blogspot.com/2005/11/platform-20.html>

Reusing these widgets recursively is an important part of the approach, and
hasn't been discussed so far. This is illustrated in another blog:

 
<http://internet-apps.blogspot.com/2005/11/xforms-flickrbar-and-flickr-strip
s.html>

in which we have a thumbnail image from Flickr, that is overlaid with the
time that the photo was taken. This time is then 'skinned' with an SVG
analogue clock. This whole package (image plus time) becomes a widget in its
own right, bound to a Flickr image object. It's obviously then an easy
matter to combine a whole load of these together to form a strip. The
screenshots then show a further step, which is that an XForms output control
containing a tag is used to find images from Flickr that contain that tag,
and then each image is rendered, with its own clock. This in turn becomes a
new widget! Yet a form author can use this image strip simply by having an
XForms output control that contains the tag to search on:

  <xf:output value="'dolphin'" />

Finally, a discussion on slightly more 'esoteric' issues is here:

 
<http://internet-apps.blogspot.com/2005/06/svg-as-stylesheet-language.html>

in which I look at SVG as a stylesheet language. There is a short video that
some may find interesting, since it shows a change in the value of a CSS
pseudo-class (hover) being used to trigger an animation (the text on a
button is zoomed in). Whether CSS property changes are legitimate triggers
for actions is a discussion in its own right, but whatever you think about
the approach, it has to be said that the days of swapping one image for
another on mouseover are numbered!

All the best,

Mark


Mark Birbeck
CEO
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/

Download our XForms processor from
http://www.formsPlayer.com/  

> -----Original Message-----
> From: www-style-request@w3.org 
> [mailto:www-style-request@w3.org] On Behalf Of Shelby Moore
> Sent: 23 November 2005 18:02
> To: Boris Zbarsky
> Cc: www-style@w3.org
> Subject: Re: Why Binding Scripting in Style Layer Conflates Semantics
> 
> 
> Hi Boris,
> 
> I think I remember interacting with you in 
> fair-minded/cordial collaboration in bugzilla.mozilla.org.
> 
> 
> Boris Zbarsky wrote:
> > OK.  So say I have a <select type="map"> as a result of XSLT.  I'm 
> > still trying to render a map of countries (from which the user can 
> > _select_ a country).  Whither from now?
> 
> 
> The difference is that with XAML the specialized script code 
> for <mapselect> or <select type="map"> only gets invoked if 
> those semantic indicators are in the markup.
> 
> Whereas, binding scripting in style layer, means the script 
> could semantically modify any tag, even a <select> which has 
> no semantic markup specialization.  If I remember correctly, 
> Ian used an example in our debate with an unspecialized 
> markup <a> tag which reinterpreted all contained text as 
> dates.  In short, there is no enforceable requirement that 
> scripting bound at style layer can not obscure semantic changes.
> 
> Of course, non style-bound client-side scripting could 
> potentially obscure semantic changes as well, but only 
> through the dynamic DOM and at least it is orthogonal to 
> style, and so user can turn off scripting independently of 
> (without turning off) style.
> 
> 
> > The idea of XBL-like things is that given semantic markup 
> like <select 
> > type="select-a-country"> (which clearly says what we're selecting),
> 
> 
> But binding at style layer means you can do these things even 
> if type="select-a-country" is not present.
> 
> Whereas, without binding at style layer, there is no way to 
> change the semantic presentation for <select> as it is 
> standardized in the browser. 
> So using the correct XSLT mechanism forces you to create a 
> binding to the code at the semantic markup layer, instead of 
> obscured (and conflated) in the style layer.
> 
> Not to mention other issues of complexity, infinite loops, 
> race conditions, etc.. that don't need to be in the style layer.
> 
> 
> > one
> > can attach different presentations (a dropdown list of 
> countries, an 
> > imagemap for which clicking on a country selects it, a set of radio 
> > buttons, one radio button per country, etc).
> 
> 
> Yes I am not disagreeing with the benefits of new semantic 
> behaviors.  I am just saying we need to put the binding to 
> the script in the semantic markup layer, not in the style 
> layer.  XAML does this semantic binding. 
> XSLT gives you transformation styling.
> 
> In short, I am trying to enable Tim Berners-Lee's semantic 
> (rich) web, not give more hooks to obscure it.
> 
> 
> > Note that producing these with server-side XSLT would 
> actually obscure 
> > the semantics (those being simply "select a country").
> 
> 
> No.  The semantics of the output would be <select 
> type="select-a-country">.
> 
> What would be obscured is the semantic style transformation 
> (from say <select> to <select type="select-a-country">), but 
> that is the benefit of putting the style transformation on 
> the server.  It must have been desired.
> 
> 
> >  Producing these
> > with client-side XSLT is possible,
> 
> 
> Yes.
> 
> 
> > and very similar in spirit to the XBL
> > approach as far as I can tell.
> 
> 
> No, very different for the reasons stated above.
> 
> 
> > So I don't see what the big argument is about, frankly...
> 
> Hope you do now?
> 
> After Daniel impuned me for making 130 posts the last time I 
> debated this, I decided I wouldn't go back and forth on this. 
>  So I think I've made my point now.
> 
> I will let you folks hash it out as much as you want.
> 
> 
> -- 
> 
> Kind Regards,
> Shelby Moore
> http://coolpage.com
> 
> 
>

Received on Thursday, 24 November 2005 19:56:48 UTC