OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Book that covers namespace issues?

The problem is that as Simon's filters demonstrate, 
the namespace practices depend on what the user or developer 
is doing with the namespace in a context that can change depending  
on the tools used and the intent (eg, who is the authority over 
the semantic).   I'm not sure we get best practices or authoritative 
recommendations without locking down the other specs more concretely, 
that is, XML Schema, infoSets, etc.  Because namespaces go beyond 
what markup languages (eg, SGML) allowed except via rarely 
implemented features (SUBDOC, CONCUR), we are very much beyond 
traditional markup experience.  XML Schema is still experimental 
despite status.  Namespaces started out as *just a property to 
distinguish names in a tree* and are now all things 
to all people because we are tieing semantics directly to 
GIs as OOPMen like to do or joining in files as tableMen have 
to do.  But XML isn't OOP or relational.  It's just a chunkOData 
made to fit the occasion.  Steve Newcomb had it right: a GI 
isn't a type name, it's a property, the BigAttribute.  The specs 
can call it anything they like, but the architecture isn't there.

Messy.  I don't think the W3C can sort this out easily.  So in 
that view, a practices document might help but I don't think 
it can do more than say why a given practice is good or bad 
in a given context.   A simple good vs bad won't do.


Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h

-----Original Message-----
From: mrossi@csc.com [mailto:mrossi@csc.com]

That would be great. But personally, I'd like to see it have some
development participation or sanctioning from the W3C. For one thing, they
started it. :-) Also, we've seen some of the brightest minds in the field
repeatedly debate many sides of these issues, without firm resolution of
most of them. Normally, I'd just go read the spec for myself. But given the
viewpoints expressed thus far, I wouldn't trust my own interpretation of
this one. We need some official answers.