W3C home > Mailing lists > Public > public-annotation@w3.org > February 2017

Re: [web-annotation] Selector Fragment URI Usage in HTML Serialization Note

From: Takeshi Kanai via GitHub <sysbot+gh@w3.org>
Date: Wed, 01 Feb 2017 05:38:18 +0000
To: public-annotation@w3.org
Message-ID: <issue_comment.created-276576977-1485927496-sysbot+gh@w3.org>
@BigBlueHat No, I'm talking about Selector Fragment Identifier only. 
We can "identify" a text on a Web page with both Selector Fragment 
Identifier with Text Quote Selector (IRI-Alice) and Selector Fragment 
Identifier with Text Position Selector (IRI-Bob), for example. Then 
the question was do we need to call the text with its name (Alice, 
If Selector Fragment Identifier is to be used to get to the text, I 
think it should be called with its location or address which tells us 
where the text is, rather than its name. It means both Alice's address
 and Bob's address should be used for that purpose.

This is a valid Selector Fragment Identifier.
Unfortunately, this is invalid as URL. To use this string as URL, we 
have to encode the Japanese text. Then, the string of IRI and the 
string of URL are not identical. If these two were identical, I had no
This is why I would like to clarify whether the given sting is "name" 
(Identifier, IRI) or "address" (Location, URL).

I could say the IRI based spec, Selector Fragment Identifier describes
 how to name fragments on Web. Thanks to the IRI to URL conversion 
method, we can get to the fragments. It is very capable and I like it.
On the other hand, I'm afraid that the original intention of Selector 
Fragment Identifier might be to provide means to describe location of 
fragments. If so, I think Selector Fragment Identifier should reform 
its basement from IRI to URL. Then this note will not need to open 
pandora's box.
What do you think?

GitHub Notification of comment by tkanai
Please view or discuss this issue at 
using your GitHub account
Received on Wednesday, 1 February 2017 05:38:24 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:51 UTC