More on Namespaces

[len bullard]

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 
assume otherwise.
 
> 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
the 
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
> example?

Not from home.  I have seen examples in which the namespace URL points 
to different things;  specs, schemas, and classIDs.  That confused me
but 
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
components. 
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
that 
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
economic 
sense.  The best way to get them follow the standards is to make it
expensive 
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
did.  
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.

len

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)