[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: So maybe ID isn't a problem after all.

• To: "Gavin Thomas Nicol" <gtn@r...>, "James Clark" <jjc@j...>, <xml-dev@l...>
• Subject: Re: So maybe ID isn't a problem after all.
• From: "Jonathan Borden" <jborden@m...>
• Date: Tue, 13 Nov 2001 00:04:26 -0500
• References: <E163Qf2-0008CL-00@s...> <360680761.1005641126@[192.168.0.152]> <E163VKJ-0000ZK-00@s...>

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>
>

• Follow-Ups:
  • Re: So maybe ID isn't a problem after all.
    • From: Gavin Thomas Nicol <gtn@r...>

• References:
  • Re: So maybe ID isn't a problem after all.
    • From: Gavin Thomas Nicol <gtn@r...>
  • Re: So maybe ID isn't a problem after all.
    • From: James Clark <jjc@j...>
  • Re: So maybe ID isn't a problem after all.
    • From: Gavin Thomas Nicol <gtn@r...>

• Prev by Date: Re: So maybe ID isn't a problem after all.
• Next by Date: Re: IDs considered harmful or why keys might be better than IDs...
• Previous by thread: Re: So maybe ID isn't a problem after all.
• Next by thread: Re: So maybe ID isn't a problem after all.
• Index(es):
  • Date
  • Thread