> Hmm. Maybe. On the other hand, it really isn't clear to me that mixing
> concrete and logical is necessarily destructive -- HTML is a good example
> of something that started mildly concrete and has been moving steadily
> more logical (as the logical operators get emphasized over the concrete
> ones). Granted, that's only a halfway counterexample, since HTML from
> the beginning was less concrete than VRML. But it's enough to make me
> wary of assertions that people wouldn't get the point; they seem to
> manage well enough in HTML.
I wouldn't say that HTML (unless maybe you count pre-1.0 versions) has
been getting at all more logically oriented. More logical elements have
been added, but a great deal of the emphasis has been on physical
formatting. And they don't manage well enough in HTML. There are many,
many people out there writing HTML that use logical markup only becuase
they are forced to; and still worse, they misuse it, and because of so
many people doing so, it's proving nearly impossible to actually treat it
as logical markup without losing horribly.
It will be quite a while before everyone feels up to logical markup for
text, and HTML will probably be a casualty in the adjustment.
However, all this is beside the point. There are things much more
relevant to be learned from text formats. Think of this: if a text-mode
browser grabs a header and sees 'application/postscript', it knows quite
well that it isn't suited to display such a file. If it sees
'text/html', it can generally assume that it CAN display the file
successfully. Similar things will come into play with shared-space
engines. This alone is almost sufficient justification for keeping
levels separate; add in the reduction in hairiness of the rendering
software and the extra modularity and flexibility and you've got more
than enough reason to maintain the separation.
> As for embedding another language -- again, mayyybe; it's an interesting
> argument. On the other hand, sticking to one clear syntax style has
> considerable advantages in parsing, and it isn't clear to me that the
> conceptual difference is so great as to warrant a clearly separated
> language.
Well, 'embedding' as such isn't even really necessary; HTTP-NG should
allow it to be done with inlines with comparatively little loss of speed.
> In principle I think you're right; in practice I worry about the
> practicality. We're talking about a lot of information to cram in, of
> a very different flavor from what generally goes into URLs, and it's
> not clear to me just how real the URN work is yet. I'm certainly
> willing to give it some time and see if URNs turn out to solve the
> problem for me; this is a large part of why I've back-burnered the
> idea. I'm not going to let it go completely until and unless it's
> clear that a better solution is on its way, though.
Well, I suppose that's wise; nevertheless, even if URNs don't come
through in this way, however, it'd probably be a good idea to come up
with something more like a URN than you are currently proposing, for
reasons of reusability in other Web applications.
> Of course, there's an element of chicken-and-egg problem here. This
> specific capability is much more useful for a VRML environment than
> for an HTML one, I suspect; at least, I can come up with many potential
> uses for it in VRML, but few in HTML. Thus, I'm not sure that there will
> be any impetus to really get a solution until VRML is out and real...
>
> But I'm always in favor of more general solutions where appropriate,
> and if URIs wind up evolving to deal with the issue, that ought to
> do fine...
Well, if anyone ever comes up with a non-HTML page description language I
foresee many uses for keyword-based retrieval: fonts, bullets, and so
forth.
-- James Deikun (University of Pittsburgh) #include <std_disclaimer.h> door (n.)- something a cat wants to be on the other side of.