[csarven]

I urge you to dig a little deeper and see why things like `prefix`, `exact`, `suffix` exists in that particular example:

https://www.w3.org/TR/selectors-states/#TextQuoteSelector_de...

Please note that you've actually changed the example!

If you just want to include `exact` or "targetText", you can still do:

http://csarven.ca/dokieli-rww#selector(type=TextQuoteSelecto...

or equivalent:

http://csarven.ca/dokieli-rww#selector(type=TextQuoteSelecto...

but that selects all instances of the text "annotation" in the document. Which is precisely why we need `prefix` and `suffix` to be able to identify the actual selection that the user made.

So, here is the equivalent of your example:

http://csarven.ca/dokieli-rww#selector(type=TextQuoteSelecto...

I hope that clarifies.

This is just tip of the iceberg! Let's stick to fair comparison and consider extensibility.

[crehn]

Even with that in mind, the W3C spec adds unnecessarily verbose syntax fluff.

[csarven]

We can only compare what's on the table, ie. arbitrary text selection. The targetText proposal doesn't necessarily result in a unique identifier that deterministically corresponds to user's original selection. So, I'm not sure if there is any point in discussing the syntactical differences on specificity further at this point. Having said that, at the end of the day, it is going to be the application that generates and uses the identifier.

Please have a closer into why we should be mindful of different use cases here, especially those pertaining to different resource representations, ways to "select", and factor in the state of the resource/representation at the time of the selection. It is there for use. It doesn't mean that all possible options needs to make its way into the identifier. This is important because people are going to use these identifiers in documents, and preserving context matters. Like I said earlier, the W3C Note has considered these, as well as permitting the use of different (RFC) selectors for different media. Let's reuse instead of NIH-FUD.

[contravariant]

It's not like (un)necessarily verbose syntax is that uncommon in URLs. Or rather that's exactly where you'd expect an excrutiatingly verbose description of what you're linking to.