[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [xml-dev] So maybe ID isn't a problem after all.
recall that only the URI part of a URI reference is sent to the HTTP server,
it is entirely the job of the client to parse the fragment identifier.
e.g. http://example.org/foo#bar , the server is sent: http://example.org/foo
and the client uses "#bar" to find something inside what is returned.
Jonathan
Gavin Thomas Nicol wrote:
> On Monday 12 November 2001 08:45 pm, James Clark wrote:
>
> > This runs into the well-known inconsistency in the Web
> > architecture: the meaning of a fragment identifier is supposed to be
> > determined by the media-type, yet a single URI reference may return
> > different media types because of HTTP content negotiation. Would it
matter
> > that you couldn't have a fragment identifier in XML that was a simple
name?
>
> I think HTTP negotiation only really works for media of roughly the same
> types, or requests for complete objects. For example, I get GIF's instead
of
> JPG's.
>
> I'd be most annoyed if I asked for
>
> http://www.foo.com/foo.xml#foo
>
> and was expecting it to conform to the docbook DTD, and got back a PDF
> file.... or worse, an SVG document, or a big TIFF image. In the face of
> content negotiation, a lot of code in the world is very much broken....
>
> Then again, this is still something of a red herring. If I asked for
>
> http://www.foo.com/foo.xml #xpointer(//*[@id='foo])
>
> and the system wanted to return generated PDF instead, it has the
> responsibility of preserving the semantics of the fragment id. If I were a
> site administrator, I'd probably have this redirect to
>
> http://www.foo.com/foo.pdf#foo
>
> Anyway, the flaw in HTTP is pervasive, and if we *really* care, this issue
> might be better fixed there.
>
> > (a) Remove the RawName construct in XPointer
> > (b) Change the semantics of the RawName construct in XPointer to say
that
> > it refers to, say, a element with a xptr:name attribute with a
particular
> > value
> > (c) Add an xml:idatt(s) to XML
>
> These are all reasonable choices, I agree.
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
>