Lists Home |
Date Index |
- From: len bullard <firstname.lastname@example.org>
- To: David Megginson <email@example.com>
- Date: Fri, 14 Aug 1998 17:53:47 -0500
David Megginson wrote:
> Personally, I'd like to separate the issue of global names from that
> of document composition: I do not think that namespaces are a useful
> substitute for subdocuments (inline or out-of-line) -- that issue
> still needs to be dealt with.
Yes. But when I read the specs and look at the examples on some sites,
the assumptions are easy to make. There are documents that use
the words "namespace" and "schema" in the same sentence too often to
> In other words, an element named "http://www.megginson.com/ + para" in
> one document and an element named "http://www.megginson.com/ + para"
> in a second document have the same name. Make of it what you will.
Ok. I understand that. Taken on its
face, if the URL is unique, the element strings are identical. It is
URL that is the unique part. It only establishes a mechanism for
making it unique. It doesn't carry the promise as a Doctype does
that at the other end of this, say, system literal is a description
which not only provides a unique local namespace, but also the frequency
and occurence of that element in an instance.
> > So what am I to assume if I see a dt: prefix that has a classID
> > in the ns attribute, and another that *appears* to point at
> > a schema of some sort?
> I'm not certain that I understand the question -- could you give an
Not from home. I have seen examples in which the namespace URL points
to different things; specs, schemas, and classIDs. That confused me
given the above, I think I understand what you are getting at. The
schema may be there but that is not the namespace mechanism.
> The WD contains much in the line of confusing and mostly-irrelevant
> philosophical musings that (I hope) will eventually be deleted -- if
> Len finds the spec confusing, I'm terrified of what will happen when
> it hits the webmasters.
Well, Len is spending his free days reading everything on the
public W3C site to work through all the specs. I don't think
one can fairly work out the system without understanding all of the
Some of this relates to work, some curiosity and the markupJones,
and some because of the issues with VRML and the kudzuProperty of
markup systems. Anyway, as I wake up from some years of insulin
deprivation, maybe my grokking will improve, so I am not a fair
comparison right now and certainly have to catch up.
> With the latest namespaces WD, however, XML can no longer fairly claim
> to be simpler or more transparent than SGML -- the contextual
> dependencies built into local scoping and defaulting are in the same
> class as the contextual dependencies built into SHORTREF and OMITTAG
> (both of which XML wisely discarded), though the algorithms for
> resolving the namespaces are considerably simpler.
I trust you are right. I never had to write code to do those and
I never used those features. Yet, perhaps it is time to acknowledge
this project is not simply SGML On The Web: given the DOM, et al, it
is the project to overhaul the WWW products and provide a stronger
and extensible, and more importantly, standardizable system. Flying
in the faces of the vendors doesn't work. We need requirements, specs,
and conformance tests. IOW, make it clear enough and cheap enough to
do the right thing so that doing the wrong thing simply makes no
sense. The best way to get them follow the standards is to make it
to do otherwise.
> It is up to the reader to decide whether the fact of this complexity
> vindicates HyTime or indicts XML.
XML won't be indicted. We will suffer for the early hype as HyTime
OTOH, we have to be clear along the lines of the statements I used to
make to the IETM community: when you say interactive, you say code.
HTML spawned a community that believed it could do multimedia without
code. While that group may mainly only consist of marketing wonks
now, we have to deal with the issue that XML 1.0 is just the syntax
piece of a much broader system that taken altogether is more
complicated than SGML because it attempts to do more than SGML
attempts. HyTime may be vindicated by something most of us
already knew and XML+TheRest makes clear: open hypermedia based
on open standards is a very hard problem. Since every document
I've read on the W3C sites clearly acknowledges parentage,
there is no call for official vindication. We just have to
acknowledge the problem is hard, we learned a lot from
the previous attempts, and now we are iterating through
yet another design, older, wiser, and ready to get it done.
> The temptation to obfuscate is hard
> to resist.
Ha! We are victims of our erudition.
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)