W3C home > Mailing lists > Public > www-tag@w3.org > April 2003

RE: Grinding to a halt on Issue 27.

From: Dare Obasanjo <dareo@microsoft.com>
Date: Tue, 29 Apr 2003 01:03:37 -0700
Message-ID: <B885BEDCB3664E4AB1C72F1D85CB29F805C1F913@RED-MSG-10.redmond.corp.microsoft.com>
To: "Roy T. Fielding" <fielding@apache.org>, "Dan Connolly" <connolly@w3.org>
Cc: "Tim Bray" <tbray@textuality.com>, "WWW-Tag" <www-tag@w3.org>

A namespace name is an opaque identifier not a hypertext link so why is
there an expectation that XML parsers will be performing "link
normalization" during processing? 

If everything seems to be going well, you have obviously overlooked

This posting is provided "AS IS" with no warranties, and confers no

> -----Original Message-----
> From: Roy T. Fielding [mailto:fielding@apache.org] 
> Sent: Tuesday, April 29, 2003 12:52 AM
> To: Dan Connolly
> Cc: Tim Bray; WWW-Tag
> >> More importantly, it is because the namespaces draft 
> cannot declare 
> >> them to be different because a normalizer has every right (and in 
> >> some cases a responsibility) to normalize those URIs before the 
> >> namespace processor even sees them.
> >
> > For example?
> >
> > I find this argument hard to follow without a concrete example here.
> Normalization of identifiers is often done by link management 
> systems to reduce unnecessary duplication of URI trees by 
> sloppy human folks, since such duplication effects both 
> downstream caches and the valuation function applied by 
> third-party indexers.  It was one of the most common feature 
> requests for MOMspider.
> I expect that similar normalizers will work on xmlns 
> attributes, with or without blessing of the specification, 
> because such duplication might have significant performance 
> implications on a system that processes and combines XML from 
> many sources (e.g., Cocoon, blogs, etc.).  Besides, its just 
> untidy, and there's no shortage of anal folks in the Web 
> content industry.
> ....Roy
Received on Tuesday, 29 April 2003 04:03:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:55:58 UTC