Norman Walsh
Norman Walsh
> With the current rules, the port is not detected in http://x:80. Maybe x: is misinterpreted as the beginning of a Windows path? Indeed, the clause `If the string matches...
> The uri decoding should be revised. It’s currently possible to create strings with invalid Unicode characters: parse-uri('%FF'). With the current rules, the following expression returns df83 and dc00: I...
> Most regex strings ends with a dollar sign, but only some of them start with a circumflex character. Maybe it’s better to use ^ everywhere? Yes, I think that...
Thank you. Yes. Let me see about that.
I can't explain why the status quo drafts don't reflect that merge. That's a little scary.
The `tel:` scheme is non-hierarchical and has an explicit leading plus, see [RFC 3966](https://www.ietf.org/rfc/rfc3966.txt). We don't mandate what non-hierarchical schemes are implemented so I think you could exclude that test...
Of course, GitHub mangled the back ticks in your example. :-) But I'm confused about where the problem is wrt the test results. The results in the test suite are...
I don't understand this comment from 26 June: >fn:encode-for-uri is applied on the members of the path-segments array, but in various tests, the path segments are adopted unchanged in the...
Right. I can see why I get the results I do, but I can't justify them. I'm only encoding the path parts of hierarchical URIs. Even in hierarchical URIs, I...
See related discussion in #774