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 Sunday 11 November 2001 03:36 pm, Daniel Veillard wrote:
> > Why special case it though? The main thing ID's buy you is a guarantee
> > that a validating parser is going to ensure the values are unique. How
> > about ignoring all the DTD and XML special treatment and simply say that
> >
> >    foo.xml?@id='bar'
> >
> > will point to all id attributes with the value 'bar', or something
> > suchlike, *in the context of your application*?
>   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




I know this is somewhat heretical, but in XLink, the only thing I've heard 
for doing anything with id is for 'simplicity' and for grandfathering HTML 
mechanisms. I don't buy either.

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

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