W3C home > Mailing lists > Public > w3c-sgml-wg@w3.org > June 1997

Re: namespace viz validation

From: David G. Durand <dgd@cs.bu.edu>
Date: Thu, 19 Jun 1997 12:42:46 -0500
Message-Id: <v03007805afcf1e2d7ccb@[]>
To: w3c-sgml-wg@w3.org
At 12:36 AM -0500 6/20/97, Michael Leventhal wrote:
>I've felt for a very long time that SGML needed a "class" mechanism (to
>me, oddly called here namespaces, but no matter) and that 1. HyTime did not
>that properly and 2. that it should not be associated with HyTime but
>rather be a
>syntatically smooth part of the element definition syntax.

In theory I agree, but only if we understand what we are doing. The
attribute approach works now, and can be replaced by a better mechanism
whenever we are _sure_ we have one. But if we add a _bad_ mechanism, we are
stuck with it. That's the terrible downside of experimenting with a

>I'm a techie who has tried his hand at teaching SGML and I've picked up
>some things.  You can't teach marked sections because they use a
>parameter entity and people don't get at all what entities are about.
>So the conditional markup proposal Tim put out interested me greatly.

You can teach anaything, but of course syntactically contorted things like
marked sections require more contortion than elegant things like
conditional markup.

But we made a decision for compatibility. And we _have the expressive
power_ as things already stand.

>You can't teach people to class elements with HyTime syntax.  Just can't.
>But oddly, they can easily understand the class/namespace syntax.

I'm not convinced of this, but I agree that the notion of "namespaces"
might have promise on a number of fronts. It just needs more work than it
can get right now, and there are functional, existing alternatives to
defining new syntax.

>So I have every reason to like the ':' proposal but I find myself
>agreeing with the statement above.  Is there really real interest to
>do something with this even before we have fundamental things done
>like styles?

Also a good point.

>However, although we have an XML tool coming out which does not read
>the DTD we do not object to having to read the DTD in a future version
>to pick up attribute definitions which, among other things, might give us
>associations.  But we feel strongly that it should also be a choice - if you
>don't read the DTD you may lose information but that is the application's
>and the user of that application's choice.  We think that the market will
>rapidly set the level of interoperability needed and, very likely, we will
>quickly arrive at the point where most applications will process the DTD
>in some form or fashion.  (Writing DTDs in XML _would_ help.)

Sure would, but we burned that bridge long ago... But it's still easy to
experiment with DTD defining tools and notations, and standardize on
something more capable once we have some practical experience.

I was a lot less unhappy about losing the DTD syntax battle once I realized
how easy it would be to create a tool to implement _my_ list of ideas as to
how DTD syntax could be reformed.

  -- David

David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________
Received on Thursday, 19 June 1997 12:41:51 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:25:10 UTC