Selectors as URI fragments

A few concerns for the IRI syntax part of the Selector Note, but the rest
of it looks great!

1.  Fragments are defined by the Media Type

I realize it's just a note, and that no one in practice respects that the
fragment specification, however I think we should explicitly state that
this is not a best practice for media types that have a fragment syntax
already specified ... such as HTML, plain text and images.

I propose to add a warning themed block before section 5.1:

This pattern should only be used when the implementation cannot produce or
manage the full representation described above.  The fragment identifiers
produced in this way have the potential to conflict with other fragments as
they do not conform to the syntax specified by the media type
registrations, when such registrations specify a syntax.

2.  Extension types produce ambiguity

As there isn't a namespace or full URI for the type parameter, different
extensions may (are indeed likely to) create ambiguity. If two
organizations create a HtmlSelector, then in RDF the URIs will uniquely
distinguish them.

I propose to add below the bullets in section 5:

For types and properties other than those specified in the Web Annotation
model, the full IRI MUST be used.

3.  SVG by value could break implementations

Some (older?) implementations of URLs have a character limit that differs
per implementation.  Embedding an escaped SVG representation in the URL
would be rejected by these implementations.

I propose to add a warning themed block after example 23:

Please note that long SVG representations will produce very long URLs when
produced according to this pattern.  Care should be taken in environments
where there is a character limit to URLs, and implementers should consider
publishing the SVG as a separate resource and using its IRI as shown in
Example 22.


Hope that helps,

Rob

-- 
Rob Sanderson
Semantic Architect
The Getty Trust
Los Angeles, CA 90049