RE: <spoiler> element

Hi Tina,

>   Yes ... the idea is an interesting one.
> 
>   Instead of agreeing on a common set of elements and their
>   interpretation, the XHTML 2 specification basically provide a
>   mechanism for overloading the semantics of existing elements.[*]

The XHTML 2 spec has many 'common' elements--if it didn't there would be
nothing to write about. However, these elements are fairly broad, and relate
mainly to general notions of document structure; head and body, obviously,
but also things like lists and sections, footers and side-bars. The latter
two are supported via @role.


>   Mapped to natural languages this can described by saying that, in
>   English, the word "foo" means - in the same context, mind - not only
>   "foo", but possibly "bar" and quite likely also "baz".

No, it doesn't. The parallel you need isn't within the realm of the
language, it's with the object itself. If I call my son 'Louis', he doesn't
cease to be my son. The same goes for if he *plays the role of* a 'Wise Man'
in the school nativity play.

So it's important to see semantics as operating at different layers, rather
than being monolithic. No-one has talked of 'overloading'; a <section> is
still a 'section', but it is now also a 'spoiler'. What each system does
with the information it now has, that some element is a 'spoiler' (or a
footnote, vCard, diary date, tourist location...and so on) is up to it. But
hopefully, if it does not understand 'spoiler', it can still process the
element as a 'section'.

This means that you could have:

  <section role="spoiler">
    ...
  </section>

Or:

  <ol role="spoiler">
    ...
  </ol>

And the semantics of a 'spoiler' would be untouched, as would the semantics
of 'section' and 'ol'.


>   However ... in order for a random user NN to gain access to the
>   underlying semantics of documents on an XHTML 2 web, he or she will
>   need a browser able to understand any, and all, of the 
> author-extended
>   language it might run across.
>
>   This theoretical UA will, in other words, need not only 
> understand the
>   basic semantics of XHTML itself, but also any overloading a random
>   author might come up with.

Well, sort of. But we can go a long way towards that with other mechanisms.
For example, as I said in my earlier email, the tricky point that Jukka's
email raises is how do we get the *behaviour* that he wants? At a semantic
level, @role="x:spoiler" is fine, and does the job. But how do we make it
show and hide, for example? The answer in this particular case, I think, is
to have a CSS property that gives us the behaviour we want, and then apply
it to any element that has @role="x:spoiler".

That way any viewer/browser could behave correctly, even if it had never
heard of 'x:spoiler'. But most importantly, it leaves it to the author and
the user (if you have personal stylesheets) to decide how x:spoilers should
behave; Scrooge may not choose to hide any x:spoilers as he browses the film
listings.


>   The task of writing such a system feels somewhat daunting, but I am
>   intrigued enough to consider starting such a project. I 
> believe I will
>   call it "Babel".

We are indeed writing such a system, and one that actually uses more
powerful techniques than those I have described here. Daunting or not, it
opens up enormous possibilities. You have to admit that at the moment the
so-called Semantic Web amounts to some great presentations and slides, but
not a lot else.

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/

Received on Wednesday, 7 December 2005 12:27:37 UTC