Re: ERB call on addressing
>>And he's right: don't use # or ? to mean something special in URLS
>>when they already have meanings...
>Huh? Read the RFC. To be precise:
>In our proposal, we are using an interpretation of '#' and '?' that
>is 100% consistent with it.
Sure, but tht doesn't mean that the RFC is entirely correct either.
One problem with RFC's is that they codify existing practise, which
is often not "the right thing". Also, RFC's are often vague because
they must encompass so much behaviour.
>I think we ought to buy into the web dogma and treat the URL part
>of the URL as opaque; including whatever-they-are parameters.
It really boils down to whether you think the Xptr is addressing
something or not.
>What we're saying is that we provide *one* semantic, namely here's a URL
>and here's an Xptr, a resource and a subresource. Whether or not we
>like it, the web has already laid down the law on the process model
>mechanics of '?' and '#' - see above. We want the linkage semantics
>without the process model mechanics. Since there's nothing like this
>now on the Web, new syntax seems the only way to go.
I have no problems with # and ?. I do not see how a query can name
a sub-resource though, or how you can query a resource addressed
Using ";" is accepted practise, and provides the right semantics
for XML (addressing), is no harder, or very little harder for CGI
programmers to support, allows combined use with fragment specs
and queries. It also works in all browsers I've tested (we use
parameters in DynaWeb).
Neither proposal is inconsistent with the RFC, but your proposal
is inconsistent with the semantics of Xptrs as addresses. So if we
go with my proposal (which is still within the letter of the RFC)
we get clean semantic separation at no cost.