RE: Why Binding Scripting in Style Layer Conflates Semantics

Shelby,

I think you are being a little cheeky accusing others of 'noise' when you
have just repeated your same confusion once again. You might want to
consider the possibility that people *have* read all of your posts, *have*
followed all of your links, *have* allowed for the fact that you have been
programming a long time, and, yes...still disagree with you!

Anyway, there I go contributing to the noise again... ;)

On the issues being discussed, they are very useful, because they raise the
question of where to draw the line between the semantics provided by the
data, and that provided by the UI. The semantic triggers for 'country' are
in the data, not in the widget. So if we are editing the following data:

  <address>
    <city>London</city>
    <country>UK</country>
  </address>

The 'countryness' of <country> might come from an XML schema, perhaps.

To make use of this data we have a form, which in turn has further semantic
information. But this time that information pertains to the UI itself. It
might look like this (in XForms):

  <xf:input ref="city">
    <xf:label>City:</xf:label>
  </xf:input>

  <xf:input ref="country">
    <xf:label>Country:</xf:label>
  </xf:input>

This semantic information is about a widget's purpose (collect one value,
collect one value from a list, collect many values, submit the values,
validate the values, ensure that value a is greater than value b, and so
on). But the semantic information at this 'layer' is *not* about the widgets
relationship to countries or cities. So an xf:input has different semantics
to an xf:select1 (for example), and it is those semantics that can be
leveraged to provide platform- and device-independent functionality.

I believe your main theme is that we actually have a "select a country from
a map" widget and this is the interesting question to address; have we
really created a new widget, or just 'skinned' an old one? I would suggest
that by creating a new widget (a map selection widget) we mix the two layers
that XForms has worked hard to separate. Whether you do this:

  <mapselect...

Or this:

  <select type="country"...

the mixing has gone on, which makes it less useful. Don't get me wrong, it's
by no means *useless*...far from it. (And if we want to talk in terms of
specific languages, I think XAML is a major improvement on what is available
now, and is going to catch a lot of other software vendors on the hoof.) But
in my view it's just not as good as the clean separation of data and UI that
is obtained by XForms, which allows you to 'late bind' the control, and in
so doing change the behaviour of your form simply by changing the underlying
data.

Have a nice holiday!

Regards,

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: 25 November 2005 02:40
> To: www-style@w3.org
> Subject: Re: Why Binding Scripting in Style Layer Conflates Semantics
> 
> 
> Note I will be traveling in islands/mountains of SE Asia for 
> 2 - 3 weeks, probably starting today, so this may be my last 
> post for a while.  When when I get back, hoping to read from 
> you all a wealth of revolutionary insights, not acrimonious 
> debate for sake of proving who is "right" on every little 
> tidbit.  The key question is whether having in markup <select 
> type="country"> is more useful than <select>??  That is what 
> Semantic Web asks you?  Nice if we could stick to that key 
> question without muddling it with irrelevant tidbits.  Noise 
> is an effective technique to kill the messange, but in 
> meantime others are moving ahead of us.
> 
> 
> Mark Birbeck wrote:
> "...operates in terms of pre-defined objects--XAML is in this 
> category..."
> 
> I have already shown that XAML allows object sub-classing, 
> which means we can add functionality to <select>, e.g. 
> <select x:Class="mapselect"> without breaking legacy UA.
> 
> 
> "...to get accessible, cross-platform applications you should 
> abstract out the task, not the tool..."
> 
> 
> Agreed.  XAML supports sub-classing.
> 
> 
> "...Shelby is making some interesting points, I feel it is 
> *he* that has not read Lachlan's post closely enough..."
> 
> 
> Trust me I completely understood Lachlan's and your points.  
> They have not changed my fundamental point, as expressed in 
> opening paragraph of this post.  Irrelevant tidbit, I've been 
> doing OO programming _commercially_ for 19 years (40 years old).
> 
> 
> "...the only interfaces that are of interest are the 'select 
> an item from a list' interfaces...this does not mean that the 
> widget that does the mapping needs to 'inherit' from <select />..."
> 
> 
> Incorrect.  You are forgetting the semantic issue, which I 
> re-summarized in the opening paragraph of this post.  The 
> markup layer needs to know that you are sub-classing the 
> <select> into a <select type="country">, so that consumers 
> (UAs, crawlers, other scripts, etc) that access the markup 
> layer will know this additional semantic information (that 
> they items are countries).
> 
> 
> "...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*..."
> 
> 
> Not at all.  Analgous to editing your XBL script, you edit 
> your markup and your code-behind .Net class, and then when 
> your Windows (or open source
> Mono) browser hits the markup, it loads your .Net class.
> 
> 
> "...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'..."
> 
> 
> We can make a .Net class and markup to handle that, 
> analgously to your XForms example.  The beauty of XAML is it 
> is fully generalized without conflating the style and markup 
> layers.  Yes you are correct about the importance of how to 
> bind.  And that is why we must bind at the correct layer.
> 
> But don't confuse this with limiting our binding 
> possibilities.  If you want selectors and cascade, then make 
> a CSS-like binding syntax for the markup layer (not at style 
> layer, not conflated with style declarations), which doesn't 
> obscure semantics of extension, e.g.
> 
> select[type="country"] { mapselect inherits from select }
> 
> But if you allow:
> 
> select { mapselect inherits from select }
> 
> Then be full aware of the complexity overhead you are putting 
> on semantic crawlers.
> 
> There are some very important design justifications for the 
> XAML syntax. 
> Read the Microsoft programmer blogs I linked to for the 
> reasons they dropped the CSS-like syntax.  And I don't think 
> even considered the semantic crawler angle (at least they 
> don't talk about it).
> 
> Mark Birbeck, I apologize I didn't have time to look at your 
> screen shots or read your blogs.  Maybe in near future.  
> Thanks for further illuminating the issues.
> 
> 
> Andrew Fedoniouk wrote:
> "...From practical implementation point of view having 
> defined  x:Class="MyNamespace.MapSelect" is not enough as 
> this does not tell me what is the superclass of 
> MyNamespace.MapSelect..."
> 
> Incorrect.  <select x:Class="mapselect"> declares that 
> mapselect is a subclass of select.
> 
> As for how to get the super class of select (if there is 
> one), then can be done via .Net CLR (language independent 
> layer) using reflection.  In my view, .Net CLR replaces the 
> DOM in .Net's model of new world wide web.  It is much more powerful.
> 
> The implications are ubiquitious.  I think we need to 
> populate the thread I started, "Future of CSS in Semantic 
> Web?".  Thanks.
> 
> 
> -- 
> 
> Kind Regards,
> Shelby Moore
> http://coolpage.com
> 
> 
>

Received on Friday, 25 November 2005 09:28:32 UTC