[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Namespaces Defined
- From: "Bullard, Claude L (Len)" <email@example.com>
- To: Dylan Walsh <Dylan.Walsh@Kadius.Com>, xml-dev <firstname.lastname@example.org>
- Date: Thu, 16 Aug 2001 12:53:15 -0500
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
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
>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...
>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.