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.



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@redhat.com  | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/