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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: Thats me with my paranoya. Really - the last one. Re: Begging theQue

[ Lists Home | Date Index | Thread Index ]
  • From: Uche Ogbuji <uche.ogbuji@fourthought.com>
  • To: Paul Tchistopolskii <paul@qub.com>
  • Date: Sat, 30 Dec 2000 10:32:34 -0700 (MST)

Great post.  Rem acu tetugit Paul Tchistopolskii.

> There is a timebomb in namespaces. To disable this timebomb the only
> thing is needed : restrict the posibility for using URL/URIs for actual
> fetching of something ( see - nobody knows *what* is that something ;-)
> and make it clear in the namespace specification that namespace names
> are *not* for fetching something ( that's what you are saying ;-).

I'd like something a bit different (but with the same effect).  I agree
with Tim Bray that it would be nice to have only human-readable
descriptions at the resources resolved by the URI.  I think this would be
a very handy link to the wetware terminals of the semantic chain.  I do
think that it should not be machine-readable data, or at least that the
spec or some other explicitly forbids resolving the NSRef for purposes of
affecting processing.

> 1. limit the ( extremely hypotetical ) possibilities of building some
> "really bright thing"  on top of  those URIs ?
>
> yes.

Disagree.  Others have pointed out how you can use other meta-data tools
such as RDF or XTM to be the foundation for this bright building.

> 2. limit the possibilities of abusing it with de-facto standard ?
>
> yes.

Which we all know is a Good Thing.

> I think it is not sane to keep this hole open. I think it will take years
> to understand what could *really* be pointed by that URL/URI and
> until that - let us close the door ? Right?

This is pretty much as Tim Bray argued in his rant, but he doesn't seem to
want to close the door in accordance.

> Let us look at this hole. Whatever will be attached to that URI  -
> it will affect almost every XML document in the world and this
> could be done at any point of time. Tomorrow. Next year.
> Next 2 years.

*Exactly*.  That is the scary part.  I practice what I preach (easy for a
lazy man to do).  There is nothing to be retrieved from any of the
http://namespace.foo.com-org-net/... NSRefs that I use in my XML.  It is
quite possible that some powerful namespace baron will come along with Tool X
and I will get so much pressure from clueless users to support the
behavior mandated by Tool X that my use of namespaces becomes an ex post
facto millstone.

> And this *blessed* schemata could be blessed *not* by W3C !

The hope is that it would in that case come from XML.org or the IETF
(maybe they could be convinced that it falls in their charter since it's
an Internet infrastructure and uses URIs).  But of course there are the
more insidious possibilities.  If MSIE 7.0 comes out with unique,
namespace-driven features, we're all in trouble.

> The wording of W3C spec allows this thing to happen and still
> be 100% conformant to W3C papers!

Yes.

> Also if ( as it have been said many times ) this thing was
> already discussed for many times, once per six months a to.co. -
> and still has no resolution in some content-negotiation
> proposal or something - maybe this content-negotiation
> is impossible to design ?

I disagree that this debate is the same as all the other namespace debates
that have raged periodically here and elsewhere.  Most of the controversy
over REC-xml-names has focused on the lack of attribute defaulting and
about the narrow scope and solution of namespaces (XMLNS vs.
Architectural forms), etc.  In the debates over URIs, including the
battle of XHTML And the Three Namespaces, I have seen little of the
viewpoint that namaespace URIs should be forbidden from serving as
semantic leg-boost.

This time the matter seems so close to solution.  Tim Bray and I seem to
agree at the heart of the matter except that he doesn't think this is a
point for REC-xml-names to make.  I'm still not clear why not.  I'm not sure
where Andrew Layman stands.  He keeps stubbornly pointing to the spec and
saying "Get thou all thy answers from this holy writ", even though it's clear
the spec doesn't answer some *very* important questions we're discussing.
Jonathan Borden makes the IMO brilliant suggestion (although probably
unlikely to fly) suggestion of using RDF available from the URI for
max flexibility.  Rick Jelliffe says let's cave and allow NSRef == schema.

But even these different viewpoints don't seem to come from
respective bastions.  I don't see that this matter couldn't be easily
reconciled.


-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS