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: Namespaces Defined

No, I mean the solution adopted wasn't in 
hand at that time.  SGML uses SUBDOC for namespace 
encapsulation.   The XML 1.0 requirements 
didn't address such things as document 
merging although the problems of that 
were well known.  They were a windy set of 
homiles about how they planned to use standards.  
If you pursue a minimum victory strategy, you win but 
you get less by definition.   It's like using 
lifelines early and bailing at the quarter 
finals so the charity gets some money over 
risking the hard questions.

Given namespace issues were controversial even 
in SGML and its solution wasn't liked 
or often implemented, it was an obvious 
"do later".  As far as fudging, the right 
thing to do would have been to fix SGML, 
not do XML, and get a much cleaner 
standard overall.  ISO did the right thing. 
On the next SGML revision, they should 
do more of that.  Perhaps an alternative 
to namespaces can start there, but we 
have to recognize that the namespace is a
system solution, not a general one.  That 
being the case, it is the system capability 
that both enables it and limits its application.

No arch-forms don't do namespaces.  It 
is a general example of how things 
considered by some to be theoretical were 
pushed away as contenders.  Again, using a 
URL to disambiguate is the problem because 
no matter how you write the spec, it is an 
address made to look like a name made to 
look like an address.  It is the reason 
the web works and its achilles heel.

The work stacking up is a symptom of 
waiting for the system to be completely 
defined and implemented in tools.  There is a long 
food chain from spec to reliable tools. 
If like me, one isn't implementing XML tools, 
but using them, other people choose the 
choices.  Schemas and namespaces aren't 
arguable for me.  I am a Thrall.  For 
that reason, next year's profits depend on 
this years victories.  The most profound 
form of malevolence is well-informed patience.

Similes are simpler and aren't confused by valid  
transforms of faulty premises.  Computers 
trust logical conclusions.  Humans are above that. :-)


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

-----Original Message-----
From: Dylan Walsh [mailto:Dylan.Walsh@Kadius.Com]

>If the namespaces solution had 
>been advanced in XML 1.0, the way out 
>if it didn't work was to roll back to 
>SGML and start over.  

Do you mean that a more clean namespace syntax would break backward
compatability with SGML? I'm not sure that would have been such tragedy.
Wasn't the issue of backward compatibility was fudged? - SGML was
changed to allow the few new features of XML. Therefore they could have
fudged just a little bit further if they wanted to incorporate a
namespace system into XML 1.0.

My impression was that the need for a namespace solution only became
apparent after the 1.0 Rec was finished or well underway. Or am I wrong?

>Given assumptions like 
>"internet time", "arch forms are worse" and 
>so on, the way it was done was the way it 
>was meant to be.   

Do architectural forms address the namespace issue? I'm not familiar
with them.

>I don't care anymore.  There is too 
>much work stacking up to start over. 

Maybe the work stacking up is a sign that we could benefit from a fresh
Hmm.. how does one go about creating your own industry consortium with
yourself as a benign dictator? :-) 
Oh, I have to invent something as important as the WWW. Damn. Anyway, I
want to be a malevolent dictactor. It is more fun. Henceforth DML
(Dylans Markup Language) shall use EBCDIC encoding, and will contain
embedded self-modifying scripting code...

>>Nice similes. 
>But that not being the case, this year, schemas are the shovel and
namespaces are the ...  :-)

Maybe I shouldn't be giving you encouragement on the simile front.