Re: [apps-discuss] Retroactive application of draft-ietf-appsawg-uri-scheme-reg - comprehensive review

[Matthew Kerwin <[e-mail]>]

On 11 April 2015 at 01:38, Barry Leiba <[e-mail]> wrote:

> > No scheme can prohibit fragments. They are not part of the scheme's
> syntax.
>
> We continue to have a confusion between syntax and semantics here.
>
> I absolutely agree that no scheme can say that fragments are
> syntactically invalid, because the schemes do not control the syntax
> of a URI.
>
> But a scheme can certainly say that fragments make no semantic sense
> within that scheme, and that if a URIs uses that scheme and contains a
> fragment, it is not a well formed URI within that scheme.
>
>
RFC 3986, S3.5: "​The fragment's format and resolution is therefore
dependent on the media type [RFC2046] of a potentially retrieved
representation, even though such a retrieval is only performed if the
URI is dereferenced.  If no such representation exists, then the
semantics of the fragment are considered unknown and are effectively
unconstrained.  Fragment identifier semantics are independent of the
URI scheme and thus cannot be redefined by scheme specifications."

To me that says that schemes cannot touch fragments at all, except
indirectly -- through representation retrieval. In the case of 'http' that
actually makes it the purview of the protocol (not the scheme), however in
'file' it's a bit fuzzier because representation retrieval doesn't have a
protocol to lean on. For URN it's completely obscure to me, because names
aren't inherently dereferenceable (?). I interpret it as: don't mention
fragments at all.



> It's rather like saying that English words are composed of characters
> from the set "abcdefghijklmnopqrstuvwxyz", and, therefore, the string
> "qwx" is a valid piece of an English word (syntax)... but that, in
> fact, no valid English words contain "qwx" (semantics).
>
> That's not a layering violation at all -- it has to be up to the
> scheme to say what the semantic meaning of a fragment is within that
> scheme, or whether fragments have any meaning at all.
>
>
​The analogy is over-simplified. If I were to write "Section 4.8.1 of RFC
1045" in some English prose, the syntax and semantics of English language
may lead us to understand that "RFC 1045" is a technical document, and
"Section ... of ..." is a fragment reference, so the question becomes: what
types of fragments can be referenced within a technical document?

If the 'English language' also defines the structure of 'technical
documents' then it can say that they contain sections, tables, and images,
for example; but if not then there's no way to know that "Quadrant 3 of RFC
6215" is nonsense, even though "Quadrant ... of ..." is also a fragment
reference.

I think it's up to the scheme to see what (if any) representations can
exist, and then those representations have to say what the fragment
semantics mean. The best the scheme can say is: "All representations are
SVG, therefore fragment semantics are defined by the W3C." Or: "There are
no representations, therefore fragments are undefined."


Cheers
-- 
  Matthew Kerwin
  http://matthew.kerwin.net.au/