[
Lists Home |
Date Index |
Thread Index
]
I trust these are people trying to do the
right things from their own points of view.
We all are. I insist on reliable processes
because these points of view are divergent.
In SGML, changes were made conservatively
because very large and very expensive systems
would be affected. Changes to XML can be a
lot more affective, so an even more conservative
viewpoint is required, IMO.
Management training is that until a case
with value is made, the answer is always No.
Why? It is easier to change no to yes than
yes to no. So far, I haven't heard the
value argument for folding namespaces into
the core. If there is no official action
to do that, then this thread can die.
len
From: Simon St.Laurent [mailto:simonstl@simonstl.com]
On Thu, 2002-04-04 at 12:30, Bullard, Claude L (Len) wrote:
> The point is not pessimistic; it is conservative.
> It is based on prior experience with the W3C
> specification process. Namespaces are a good
> example.
>
> First, they were just name disambiguators, hidden
> system properties, then schema references, making them
> part of the content. We seem to stay on the
> slippery slope of minimalism and incomplete
> design guidelines. That makes these processes
> unreliable.
I have to share Len's concerns about the slippery slope here, especially
given (unofficial, but deeply misguided IMHO) postings like:
http://lists.w3.org/Archives/Public/www-tag/2002Mar/0016.html
The "need for speed" in namespace dereferencing? Scares me pretty
thoroughly and makes me wonder whether namespaces were a good idea yet
again.
> So experience says, don't believe or trust;
> specify, verify, and hold
> to the original agreement until a case is
> made for change which adds value, not simply
> specification compression.
"Trust but verify" doesn't seem to be enough these days.
|
