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


Re:  So maybe ID isn't a problem after all.
On Sun, Nov 11, 2001 at 04:53:33PM -0500, Gavin Thomas Nicol wrote:
> >   Because of the IETF framework. The fragment identfier is the way web
> > aware application are supposed to found the expression of the sub resource
> > pointed to. From my point of view the Web framework is not something I
> > would go against. Also since 97 everybody expected to have foo#bar - when
> > the resource foo is delivered as an XML resource - to point to the element
> > carrying the ID "bar". Again breaking this expectation would be pretty
> > major.
> 
> OK. How about changing it to
> 
>    foo.xml#id='bar' 
> 
> or
> 
>   foo.xml#myid='bar'
> 
> I know this is somewhat heretical, but in XLink, the only thing I've heard 

  Hum, you should have a good idea of what it would take to try to push
such an "heretical" design though a standard process. Not for me, thanks !

> > It's a special rule versus breaking the Web framework or/and an expected
> > processing people have taken for granted for years now.
> 
> IMHO, this is bogus rationale. The 'breaking web framework' is using fragment 
> identifiers.... which is still pretty much open territory, though XPointer 
> has the nod there. I think XPointer is overkill for this too... 

  Well, If you think starting somthing against RFC 2396 is gonna fly,
you have the right to try by yourself :-)
  Considering XPointer being overkill, well the current small framework
for fragment identifier is supposed to be built by specifying one
syntax (and the associated semantic) for each mime-type. I tend to
agree that this framework:
  1/ has not been extensively tested (HTML and ???)
  2/ is far too limited considering XML syntax flexibility
  3/ fell short in case of content-negociation
but I wouldn't suggest to allow multiple bindings for a given Mime-Type.
The Mime-Type is not representative of the reall resource content and
expected processing anymore, and fixing this sounds horribly hard ...

> As for the expected processing... I contend that overall the numbers of 
> people using ID's vs. those using anchors for linking is small.

  Well, if browsers had actually *implemented the f...g spec* then maybe
that id=xxx would have been used !!! Not an error at the specification 
level but a serious lack of standard compliance as usual for HTML :-( .

I don't buy your counter example :-), name=xxx works on an identical level,
the users don't even know if it's an ID or not. They know that #foo will
go there and that's all they look after.

Daniel

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

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.