Re: New Working Draft : BECSS

On Sun, 7 Nov 1999 19:16:54 +0000 (GMT), you wrote:

>On Fri, 5 Nov 1999, Jan Roland Eriksson wrote:
>> (there are no <counter> _elements_ that I know of)

>You misunderstood. I actually did mean <counter> _element_ -- I was
>referring to a hypothetical XML language.

With all due respect, aren't _all_ XML applications hypothetical?
We are talking about web deployment of documents, right? As in an XML
document being served from a random server to one or many random users.

1) I can make up my own tags as I go (the XML hype for the press)
   I use them to markup a well formed XML doc, and I have a doc
   that means absolutely nothing to any one else but possibly myself.

2) Someone in the background says "but you can design your
   own DTD for that XML app". Oh yea, but "wrong answer" never
   the less. A DTD only creates a _syntactical_ restraint for the
   markup, nothing else.

3) Someone else tries "but what about NAMESPACES then?", so what
   about them? Would they convey any more really usable and
   verifiable meaning about my markup? No, of course not.

4) But what can I do then? Oh yes, I can attach a stylesheet to
   my XML doc and when someone views it in an XML/CSS capable
   browser he will get an _impression_ that there is some true
   meaning hiding in that markup.

5) Some random user looking at that document in a non XML and/or
   CSS capable browser, will at best be staring at several lines
   of completely monotonous content, possibly also including the
   markup it self.

6) Which in turn brings up the question...
  "Is a ua.css really meaningful in an XML browser?"
   Let my answer be clear: No.

Sorry for the rant...
But I came into SGML (and the works of "Goldfarb and friends") all to
late to be able to give any input at the time when this discussion
should have been done. I freely admit that it took me a lot of thinking
to get my tokens to fall down on the idea of "Architectural Forms" as a
way to formally attach some meaning to markup.

<URL:http://www.deja.com/=dnc/msgid.xp?MID=%3C34E9CBC9.401B6BB0@isogen.com%3E>
(yes, I'm very careful to save arjun's links, they are educational)

The designers of XML took off in another direction, why? I don't know
(same difficulty of understanding the real beauty of the concept may
have stood in their way perhaps?)

>Ok, let me try again:
[...]

Don't take me for stupid :) I do understand what you are trying to say,
and XML/CSS will most probably work very good in a "single domain"
situation where the environment of participants can be controlled to
some level.

But, it _will_not_ "work" on the www for deployment of verifiable
documents, because XML docs can not be validated as belonging to a
specific *class* of documents where the markup actually conveys a
meaning about the content.

You may want to think a bit about your <catalog...> element. What if the
word "catalog" means something completely different to some one in an
other part of the world that it mens to you and me?

How can he verify the real meaning of your markup?

XML can't be used on the www, that's for sure, unless we accept that the
doc publisher is allowed to "put on a show" for users, that users can
not control in any decent way. That may be what the "market" wants in
fact, I have my suspicions about it at least.

Transforming XML docs into XHTML may be a slightly better way to go.
Hopefully the XHTML spec will at least outline some resemblance to the
"through consensus arrived at" meaning of HTML markup.

Producing HTML docs for the www is still "acceptable",and will be for a
long time to come, even though W3C never bothered to publish an FPI for
the "Architectural Form" of HTML, so it's not verifiable there either,
but at least we do have that "through consensus arrived at" meaning of
HTML markup.

Finally, we could of course go all the way and start using the ISO/IEC
standard for HTML4 instead. There you have an "Architecture" defined,
public FPI published, and the full possibility to verify a document in
all its aspects (section 9.2)...

  <URL:http://woodworm.cs.uml.edu/~rprice/15445/15445.html>

...and for completeness, I have learned about what more attributes that
could be used...

  <URL:http://www.ornl.gov/sgml/wg4/docs/1957.htm>

[...]

>...). BECSS also makes pages smaller (code appears only once) and is
>easier to maintain. And so on.

Well, ok, that's a good thing for authors then.

>> By giving up the "I want to be in control" attitude and ask my self
>> if I really need this functionality to start with, and more
>> important, what good will it be to the user.
>
>Need the functionality? Well, yes, since this could be a critical part
>of a particular web-based application.

If you mean that "client side generated content" could be a _critical_
part of a www application, you may want to think again?

>What good will it be to the user? Pages with the same content and same
>behaviour would be smaller, so performance would be greater.

That's "wishful thinking" at best, any "new and flashy" technique
deployed, always ends up being abused to some level.

>(The arguments for BECSS itself are the same as those proposing that
><font> be yanked from HTML and put into CSS in the first place.)

That comparison limps a bit. The FONT element did not generate content
into a doc on the client side, neither does the font properties of CSS.

[...]

>You have not provided an equivalent way of doing what I describe using
>four lines or less of markup.

I was not trying to do that, my target was to make you see that there
may be a different philosophy available about the www, different from
yours, as it appears to me.

I.e. I can provide content, _suggest_ styling if I find that amusing,
but I would never make styling (or scripting) required in order to let
users make absolute and full use of 100% of my original content.

You and D.G. can go ahead, something good may come out of it in the end,
who knows, but I'm out of here as of now...

-- 
Jan Roland Eriksson <jrexon@newsguy.com>
<URL:http://extra.newsguy.com/%7Ejrexon/>

Received on Tuesday, 9 November 1999 15:14:29 UTC