Re: banana-rdf libs for scala-js

On 3 Jul 2014, at 05:06, Austin William Wright <aaa@bzfx.net> wrote:

> The problem with ports, is that a URI with an explicit but default port is not necessarily the same resource as without the port. Though, a specific scheme can define specialized semantics. HTTP defines the port to be 80 by default. Though even here, we run into problems because HTTP can go over transports other than TCP. So it's a tricky question all around.

I don't think that is relevant.

RFC3986 states http://tools.ietf.org/html/rfc3986

[[
     A scheme may define a default port. For example, the "http" scheme
   defines a default port of "80", corresponding to its reserved TCP
   port number.  The type of port designated by the port number (e.g.,
   TCP, UDP, SCTP) is defined by the URI scheme.  URI producers and
   normalizers should omit the port component and its ":" delimiter if
   port is empty or if its value would be the same as that of the
   scheme's default.
]]

The URI scheme for HTTP defines the default port to be 80 for https it is 443
It is quite clear that normalisers and producers should remove the port. Another way of saying it is that a 
URI with the default port and one without it refer to the same thing. This is an analytic truth, ie true
in virtue of the meaning or definition of a URI i.e. RFC3986

The Scala code I mentioned has a whole list of default ports.

> 
> I would note (new Foo)==(new Foo) is always going to be false because they're two different instances of Foo.

Ah yes. Aparently _.isEqual of underscore would have given me what I wanted.

> 
> How about an `IRI#equals()` function?

yep

> 
> There is an removeDotSegments function, though it's not in the prototype. I probably should expose an `IRI#toCanonical()` function. Until then, you could try `iri.resolveReference(iri)` which is effectively the same.

Thanks.

	Henry


> Austin.
> 
> 
> On Wed, Jul 2, 2014 at 8:33 AM, henry.story@bblfish.net <henry.story@bblfish.net> wrote:
> 
> On 30 Jun 2014, at 19:19, Austin William Wright <aaa@bzfx.net> wrote:
> 
>> The 'iri' module has most of the features that the 'url' module already has, however the implementation varies in that it's implemented using the vocabulary found in RFC 3986. Node.js uses invented names like 'pathname' and 'search', the official ABNF productions are named 'path' and 'query', respectively.
>> 
>> Additionally, I aim to implement RFC 3986 URI reference resolution to the letter. Node.js's url.resolve() call operates in some peculiar ways that the core developers are unwilling to correct.
>> 
>> I may opt to change the public API in the future, right now everything is a function, and many of the calls (like query()) return a leading character like "?" if not null, which might not be the easiest to use. (This is the same interface that I forked from webr3.) Remember to use semver semantics and depend on "~1". I don't have any particular ideas though, if you have any ideas, feel free to throw up an issue on GitHub.
>> 
>> The functionality not found within 'url' is the ability to convert a URI to an IRI and vice-versa. E.g., converting the following IRI (encoded here as an ECMAScript/JavaScript string):
>> 
>>     "http://example.com/\u2713"
>> 
>> Into the following URI (that contains only 7-bit characters):
>> 
>>     <http://example.com/%E2%9C%93>
>> 
>> HTML, XML, Turtle, RDF, and most formats that allow Unicode actually use IRIs, but HTTP and other network protocols only use URIs, and so have to be converted.
>> 
>> Note that a URI is also a legal IRI, this means that any IRI with unicode characters has multiple IRIs that identify the same resource.
> 
> Indeed I prefer the naming.
> One thing I don't like with the node Url class is that it does not deal with default ports correctly, and it looks like
> this library follows suite. This means that one has to write special code for equality testing. 
> It also looks like it would be useful to have a canonical method to transform URLs into a canonical format
> eg new IRI("http://bblfish.net/people/henry/../jane#me) .canonical == new IRI("("http://bblfish.net/people/jane#me) 
> should be true
> 
> In Scala there is a very nice library called spray [1] which has a Uri class [2] that does all of that
> very nicely ( even if there is an issue with relative Uri resolution ). See the test cases
> 
>   https://github.com/spray/spray/blob/master/spray-http/src/test/scala/spray/http/UriSpec.scala
> 
> Porting that to ScalaJS is pretty close to being feasible. It just requires parboiled2 to be ported to
> ScalaJs which it has nearly been ( and then adapt spray to parboiled2 as it is using the previous 
> version currently ).
> 
> Henry
> 
> 
> [1] http://spray.io/documentation/1.2.1/spray-http/
> [2] https://github.com/spray/spray/blob/master/spray-http/src/main/scala/spray/http/Uri.scala
> [3] https://github.com/spray/spray/blob/master/spray-http/src/test/scala/spray/http/UriSpec.scala
> 
>> 
>> Austin.
>> 
>> 
>> On Mon, Jun 30, 2014 at 2:31 AM, Adrian Gschwend <ktk@netlabs.org> wrote:
>> On 30.06.14 11:27, Ruben Verborgh wrote:
>> 
>> > I recently saw https://github.com/Acubed/node-iri pass by on this list;
>> > however, I think that Node's url module does what you need:
>> > http://nodejs.org/api/url.html.
>> 
>> I had a look at node-iri as well but was a bit confused what the
>> difference is to the node URL module (except structure of it). Austin
>> could you give some comments on that?
>> 
>> regards
>> 
>> Adrian
>> 
>> --
>> Adrian Gschwend
>> @ netlabs.org
>> 
>> ktk [a t] netlabs.org
>> -------
>> Open Source Project
>> http://www.netlabs.org
>> 
>> 
> 
> 
> Social Web Architect
> http://bblfish.net/
> 
> 

Social Web Architect
http://bblfish.net/