W3C home > Mailing lists > Public > www-archive@w3.org > November 2004

RE: Semantic Argument (Warning: Long Post)

From: Doug Schepers <doug@schepers.cc>
Date: Sun, 14 Nov 2004 03:03:59 -0500
To: "'Ian Hickson'" <ian@hixie.ch>
Cc: <www-archive@w3.org>, "Danny Ayers" <danny.ayers@gmail.com>, "Philippe Lhoste" <PhiLho@GMX.net>
Message-Id: <20041114080359.8E032149690@pillage.dreamhost.com>

Hi, Ian-

I see that we have fundamentally different visions for the future of the
Web. I have little expectation that I will change your mind, but in case
you're interested, here's my perspective. Thanks for replying to my rather
off-topic email.

Ian Hickson wrote:
| 
| Since this isn't really about SVG per se, I've not cc'ed 
| www-svg. Feel free to post this or follow-ups to www-svg if you like.

I agree it's best to keep this offlist, so as not to gum up the works of SVG
1.2 LC. I got private replies from a couple of people, so I thought that
they might be interested in my reply.


| On the Web, what I refer to as "semantics" is markup which 
| the user's UA can interpret to handle the content in ways the 
| author did not primarily intend. For example:
<snip />
|  * SVG's <text> element is semantically poor on the Web because:
| 
|     2. It has no defined conceptual meaning beyond being a graphics 
|        element consisting of text,
|     3. Non-graphical UAs can only handle it in one way: a stream
|        of text. They have no way of knowing what the context of
|        the text is.

Mostly true. The fact that it is text is sometimes the only semantic cue
that is needed to put the content into context, but not often enough. 


|  * An element in a custom namespace bound to SVG using sXBL, 
|  or a custom   element that is styled using CSS, is 
|  semantically poor because:
| 
|     1. The element will not be natively implemented by any 
| 	   Web browsers, 

That's yet to be known. Perhaps not this year, or even in 5 years (though it
wouldn't surprise me to see more browsers supporting richer semantics in
that timeframe), but eventually browsers will support something completely
different than HTML and SVG, and probably to the exclusion of those
"old-fashioned" languages. Long after the current presentational and
quasi-structural layers have dropped off the face of the Web, content with
sufficient semantics will be able to be reframed in the new idiom.


|        it will only be usable in the context of  
|        the sXBL binding or the CSS stylesheet,

Or whatever languages XBL bridges to, or however future browsers interpret
it. In many cases it would be silly to represent some content in SVG to a
sightless person, and so that UA would use the appropriate presentation
(which could be provided by the author, the user, or a third party).


|     2. It has no defined conceptual meaning that is not tied to 
|        the binding or stylesheet,

Exactly the opposite. The conceptual meaning is tied into the ontology
itself, and is therefore more rich and robust.


|     3. The elements can only be rendered by user agents that 
|        implement SVG (for the binding case) or CSS (for the 
|        stylesheet case).

Even if that were true, which I don't believe it is, I don't see the harm in
that, compared to converting things to HTML and using only the semantics
available there.


| That's not at all what I said. The semantics afforded by HTML 
| are suitable for many millions, if not billion, of pages, 
| such as FAQs, documentation, home pages about people's cats, 
| contact pages, and all the other things people say to each 
| other regularly.

Yes, but that's only a small part of what could be represented on the Web.
Those things are the activities people do on the We now because that's all
that they can do. I see the need for far more complex data and
representation in the future, as well as quotidian text. It doesn't harm
that kind of data to have another kind on the Web as well.



| The semantic value is that everyone else can interpret your content.
| If we have a bazillion markup languages, one for each domain, 
| then Web browsers aren't going to support them all, and the 
| accessibility of the markup is lost.

Not for the users it's intended for. And the model is not that Web browsers
need to support them all natively... I see XBL as acting like a Semantic
Plugin system.


| It's good enough, though, for most of what people write. It's 
| good enough to make the text accessible -- to allow it to be 
| analysed for simple uses (document outlines, e.g.), to be 
| rendered in different media (visual, speech, braille, etc).

My concern is that that's the only thing the Web will ever be if there isn't
a progressive technology developed.


| > Why is semantic markup styled with CSS better than semantic markup 
| > styled with SVG? I submit that it isn't.
| 
| It wouldn't be, if that's what you actually had. But it 
| isn't. The sXBL model, for instance, requires an <svg> root 
| element. You can't take an HTML document and "style it with 
| SVG" the way things stand now. (That was part of my technical 
| comments, in fact.)

Maybe not, but you could model the HTML in SVG. Why does the root matter?


| The biggest problem, though, is that you can write content 
| purely in SVG, without the semantics. 

You can, but if there's an sXBL component that already does the conversion
for you (made by some third party, for sale or for free), it will be easier
to use that one and simply include the actual semantic content.


| That's the problem
| XSL:FO has too, and the problem HTML 3.2 had with <font>, 
| <br>, and <table border>. People in general don't understand 
| semantics, 

I'll bet many people do. They use specific jargon and specialized
terminology within their fields. Just because they don't care about the
limited semantics HTML offers, because it gains them too little to bother
with, doesn't mean that they aren't very invested in their own semantics.
I'll bet that they will use semantic content when they think it's
appropriate to their needs.


| so if you let them write documents using a 
| presentational language, and if it will work in Web browsers, 
| they will. 

Not if it's easier to do otherwise.


| We side-stepped the problem with XSL:FO because 
| browsers never implemented it, but with SVG, browsers are 
| most likely to end up support it, and so we (the Web 
| standards community) have to make sure that SVG's design 
| doesn't encourage authors to write documents purely in SVG 
| without the higher-level semantics ever existing.

You can't stop people frommaking bad content. You can't. People will take a
perfect system and misuse it. But that doesn't mean we need to cripple
people who would us it properly. Opera and IE and Firefox all render both
well-structured XHTML and crappy tag soup; should it not give the inherent
advantages to the well-structured XHTML, things like tooltips for acronyms? 


| Same as CSS, sure. And in limited environments with only a 
| few thousand people, or in intranets, that might be fine. But 
| on the Web you have to deal with over half a billion people.

Not all at the same time. How many people are really going to be interested
in complex molecular frameworks? Does that mean we shouldn't enable those
who want to use the Web to further their research and collaboration and
data-sharing?


| In fact, it isn't clear that there is a demand from actual 
| Web authors for the detailed semantics that RDF can offer. 
| Semantics are important when they improve communication -- 
| RDF's level of semantics is great for inference-style data 
| analysis, but it isn't clear that they actually improve communication.

No, it isn't clear. I agree. However, what is clear is that they are never
given a real chance to explore this option, the Web will remain only as
superficial as it is today.

In the old days, back in the early/mid 90s, everyone coded their own HTML by
hand. But then WYSIWYG tools came along that abstracted the code layer, and
even more people started talking about their puppies and games and such.
When tools come along that leverage easy domain-specific semantic markup
(and I know people who are making such tools), more and more people will use
it, because it helps them; it helps them search for related topics, and lets
their content be found, and gives structure to a multitude of jumbled
documents. This is a problem that is best solved by humans and computers
"collaborating," and I think a growing number of people are becoming aware
of that, in a variety of fields.

Before mobile phones were common, people didn't have nearly so many uses for
them; with ubiquity, people are finding uses for them that could not have
been predicted before it happened. I think that the same will occur with
rich semantic content.
 
Regards-
Doug
Received on Sunday, 14 November 2004 08:04:02 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:42:49 UTC