> The XQuery format also seem to suffer from the disease that everything
> must be an http URI even when, as in this case, the URI is not
actually
> resolvable. (http://www.w3.org/2004/10/xqt-errors is a real page but
the
> fragment ID doesn't point to anything.)
If I remember correctly, at some point the idea was to have it point to
a description of the error...
Best regards
Michael
> -----Original Message-----
> From: [mailto:public-qt-comments-
> ] On Behalf Of Elliotte Harold
> Sent: Thursday, December 16, 2004 7:51 AM
> To: Michael Kay
> Cc: 'Rich Salz'; ;
> Subject: [XQuery] Re: [xml-dev] draft-rsalz-qname-urn
>
>
> Michael Kay wrote:
>
> > The XQuery specification, incidentally, defines a mapping of error
> QNames to
> > error URIs. It's different from this one, of course.
>
> The error URIs in the XQuery spec look like this:
>
> http://www.w3.org/2004/10/xqt-errors#XPST0017
>
> Something similar has been tried before in XML digital signatures and
> RDF. For reasons elucidated in the draft proposal, this format is not
> suitable for all QNames and does not work as a generic mechanism for
> encoding Qnames as URIs.
>
> The XQuery format also seem to suffer from the disease that everything
> must be an http URI even when, as in this case, the URI is not
actually
> resolvable. (http://www.w3.org/2004/10/xqt-errors is a real page but
the
> fragment ID doesn't point to anything.)
>
> I agree with most of your concerns about the details of the proposed
> qname URN scheme (IRIs vs. URIs, percent encoding, etc.) but at a
> fundamental level I think the proposed scheme is better than what
XQuery
> is proposing. I would suggest that XQuery adopt the new qname URN
scheme
> rather than using http URIs to identify error codes. In fact, I'll cc
> this to the XQuery working group to register it as a formal comment.
>
> --
> Elliotte Rusty Harold
> XML in a Nutshell 3rd Edition Just Published!
> http://www.cafeconleche.org/books/xian3/
>
http://www.amazon.com/exec/obidos/ISBN=0596007647/cafeaulaitA/ref=nosim
