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


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] more QName madness

[ Lists Home | Date Index | Thread Index ]

On Thu, Nov 14, 2002 at 10:27:01AM -0500, John Cowan wrote:
> Daniel Veillard scripsit:
> >   but what about URI-References ;-)
> >   <fragment href="foo.xml#[XPointer]"/>
> > you still need the context to get hold of the resource and then be able
> > to do the XPointer computation. 
> In that case, the meaning of the relative URI is determined by the context
> (viz. the location) of the embedding document, *not* by its content.
> This distinction is fundamental, though I admit that xml:base blurs it.

  s/blur/break/ as well as entities references which were here from the start, 
and the BASE in HTML breaks it too. RFC 2396 clearly put a layer
related to the document content in its section 5.1 Establishing a Base URI
Sorry that doesn't hold :-)
 You may have to analyze the document content to make sense of an URI-Reference.
If that URI-Reference also contains a fragment identifier, the semantic of
that fragment identifier is said to be related to the Mime Type of the
resource returned. Nothing in 4.1. Fragment Identifier seems to prevent
the fragment ID to also depend on the enclosed document content, but maybe
I didn't found the right sentence :-)
 Don't get me wrong, I'm not asking to remove xmlns(), but just that I don't
see the point of making them mandatory for URI-References done from an XML


Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard@redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/


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

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