W3C home > Mailing lists > Public > www-style@w3.org > November 2005

RE: Why Binding Scripting in Style Layer Conflates Semantics

From: Shelby Moore <shelby@coolpage.com>
Date: Fri, 25 Nov 2005 09:10:16 -0500 (EST)
Message-ID: <4513.203.168.9.118.1132927816.squirrel@webmail6.pair.com>
To: www-style@w3.org


Mark Birbeck wrote:
"...you are being a little cheeky..."

It wasn't directed to you, thats why I put it at top above your comments. 
It was a forward looking defense due to my expected absence.  Your logic
is most appreciated, as you are cutting into the essense (semantics and
architecture) of the matter (not 'tidbits').


"...you have just repeated your same confusion once again..."

You will see below that I did understand your point and I meant what I
wrote last time.


"XAML...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."

And I am saying that XAML can do this.  In XAML, your contained children
can be any semantic markup you want, e.g.:

<select x:Class="SmartDataSelect">
   <string x:Class="City">city</string>
   <string x:Class="Country">country</string>
   <int x:Class="Longitude">longitude</string>
</select>

And the on-demand C# .Net code would look like:

class SmartDataSelect : select {...}
class City : string {...}
class Country : string {...}
class Longitude : int {...}


As I wrote in my previous post, "beauty of XAML is it is fully generalized".


"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."


Agreed.  If the entire <select> is country data, then you could put the
semantic scoping at the <select> level (parent widget tag), but of course
I agree with you that in some cases finer granularity semantics is better,
and XAML can handle it.  It doesn't mean that finer granularity is always
better.  The granularity is a variable to give to the world and let the
world use.  I am sure you agree.  And not just granularity, but mix and
match, e.g. the <select> could be a semantic sub-class and children as
well.  The permutations boggle the mind.

And make it clear that semantic granularity was NOT what Lachlan was
writing about.  He was writing about the dividing line between style and
semantics.  At what point is something style or semantics?  And I think
that is a crucial question for the other thread I started "Future of CSS
in Semantic Web?".  But at one end of sprectrum, in Lachlan's example, I
think we all agree that green is a style of header tag, not a semantic
variable.


"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."

No I didn't limit myself to that semantic granularity.  I just didn't want
to confuse people.  Three years ago I tried to put too much in my opening
post, and I think that is what got me misunderstood.

So yes I agree with you that semantic granularity is a variable we need to
have in our architecture, and I think XAML has it.  Someone could do a
taxonomy comparison of XForms and XAML (where they overlap and where they
are different).  I am just trying to get the ball rolling on exploring
these sort of thought processes on list.  If I could just get my point to
stick, I could sit back and relish in the intelligence of this list taking
it from there better than I ever could alone.  But until I get people to
have that eureka moment on what I am saying, then I am here trying to get
it across (after 3 years).


-- 

Kind Regards,
Shelby Moore
http://coolpage.com
Received on Friday, 25 November 2005 14:10:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:54:41 GMT