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


fragment identifier redirect
On Monday 12 November 2001 08:45 pm, James Clark wrote:
> (i) Tim observes that the author will usually know what things are IDs.  I
> agree, but I don't think this solves the problem.  There are only two
> places where the ID-ness of an attribute can be specified: in the
> referenced document or in the fragment identifier.  It is not workable for
> the ID-ness of an attribute to be specified by markup in the referencing
> document outside the fragment identifier.  

Tim's point, I believe, is that from an authoring intent perspective, the 
ID-ness is irrelevant because the author knows what he's doing.

> (ii) I understand Gavin to be suggesting that we simply get rid of the
> RawName construct.

Better that than kludges...

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


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.