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


Help: OASIS Mailing Lists Help | MarkMail Help

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


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
> > that you couldn't have a fragment identifier in XML that was a simple
> 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
> 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
> > it refers to, say, a element with a xptr:name attribute with a
> > 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>