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


Help: OASIS Mailing Lists Help | MarkMail Help



   Preparing to move on

[ Lists Home | Date Index | Thread Index ]
  • From: Uche Ogbuji <uche.ogbuji@fourthought.com>
  • To: Tim Bray <tbray@textuality.com>
  • Date: Sat, 30 Dec 2000 15:12:05 -0700 (MST)

I'm glad of Tim's recent clarifications.  They help me marshal my own
thoughts and prepare to move on, invoking a modified form of the Treaty of

> >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.
> Nope.  I want human-readable material *plus* links to related
> resources (schemas, etc), these links having associated metadata
> to facilitate automated processing. -Tim

I was unclear.  My strict wording would rule out RDF and SOAP, which I've
already pointed out I think are fair (if sometimes technically
problematic) use of namespaces.

What I meant was that *by default*, i.e. unless the XML application were
ruled by another open spec such as RDF or SOAP, I would like
human-readable text only.  I guess this thinking would also be extended to
the class of XML applications governed by XSchema, based on what I
understand, through others, of the relationship between XSchema and XMLNS.

What would then be nice is a vocabulary that formalizes how applications
regard namespaces.  The RDF, SOAP and XSchema examples above would
represent sort of a DOM Level 0 analogue of established practice, and XML
Namespaces Level 1 could establish the human-readable default and then a
framework for standardized use of namespaces beyond that.

This would make it much harder for a Tool X to emerge, and as a bonus, if
XML Namespaces are the type-identifier mechanism of the semantic Web, it
would seem to align with the SW grand vision.

> >Precisely.  The matter could be addresed in an additional layer, or in
> >REC-xml-names.  I'm neutral on that point.  I only suggest modifying
> >REC-xml-names because I imagine it's the path of least effort.
> The chance of anyone in their right mind being willing to take
> on another whack at the namespace tarbaby is essentially zero.
> So I think an additional layer is the way to go. -Tim

This is the practical second half of the treaty.  Who indeed in their
right mind wants to do the heavy lifting of establishing this framework?
I must acknowledge the good and thankless work of Tim Bray, Andrew Layman
et alii, even having myself harrassed them, and I'm pretty sure I'd be
wary of undertaking any public work in that controversial space.

I'm guessing that the specification vacuum will continue to be there for a
while, and maybe in the end there is no harm.  I got into this not because
I thought the vacuum was the end of the world, but because people were
waving off Paul's questions and comments by saying they were a rehash of
things that have been addressed by REC-xml-names.

But I think I've made the point every way possible, and it's time to go
back to my very productive work with XML 1.0 and XML Namespaces 1.0.

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