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: SAX Filters for Namespace Processing

This is the parsing specialist point of view. 
This point of view dominates XML's early design 
in which OOPisms were avoided (the pixie-dust 
stories).  It is a good point of view insofar 
as the basic specification is concerned.  It 
deliberately turns a blind eye to the downstream 
processing and use of the parsed data.

So is precisely: Sounds Good Maybe Later.  You 
can't have it every way possible without conflict. 
Minimal victory depends on avoiding conflict until 
it cannot be avoided.  Then the resolution depends 
on avoiding lots of different interests by getting 
"the right people" (defined as those who concur with 
the founder's point of view) into a group to quickly 
burrow something in under the radar.  Then colonize.

Complex systems developments do not cohere in open 
development scenarios.


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

-----Original Message-----
From: Tim Bray [mailto:tbray@textuality.com]

At 11:38 PM 04/08/01 -0700, Tom Bradford wrote:

... hundreds of lines of rhetoric about how the Beautiful Primitive
    Noble-Savage Simplicity of XML 1.0 is being sullied by layers of
    "academic" onanism, of which namespaces are said to be an example ...

And it's perfectly OK not to like namespaces.  Lots of people live
in monolithic vocabularies and don't have the problems they're
trying to solve, and there are other solutions to those problems
(cf Architectural Forms) that many people like better.

>Again, not really my point.  It was argued that namespaces are
>essentially the determining factor of what an element 'means' in a
>specific context, and that is in no way an absolute truth.

I'd go further; it's a ridiculous claim that nobody sensible
has ever made.

A point I've argued many times is that markup isn't about meaning
at all; XML just gives you a way to send a bundle of labeled
strings of text, with recursion and internationalization, from
point A to point B.  Namespaces allow the labels to come from
multiple vocabularies, and make it cheap for software to find
the labeled chunks it cares about.  This is the value proposition.

The problems of how you tie labels to semantics, and how you express 
semantics, are both gateways into large complex arenas of debate
where we observe little consensus and few canonically-agreed-on
best practices.  XML is only useful insofar as it doesn't get
co-opted into one of the factions or theories in this space.  It
is useful for programmers, and good for high-value information,
to express it in an open, labeled textual form that is as 
human-readable as possible.  The world seems to share this view.
Many of us think that it is also useful and good to qualify those 
labels by URIs in order to solve collision and recognition 
problems.  The larger community of actual programmers writing
actual code seems to mostly buy in, but there remain pockets of
fierce resistance (although I've never encountered any outside
of the W3C and xml-dev).

Once again: XML doesn't do semantics.  Namespaces don't do 
semantics.  These are just labels.  Labels are good and useful
and you can't build semantics without them; how you actually
do build semantics remains an open question.  -Tim