Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
Austin Wright
@awwright
@vhf Any specification that uses WebIDL... DOM API, IndexedDB, WebSockets API, WebRTC API, Bluetooth, ...
elf Pavlik
@elf-pavlik
only difference seems with how one would use that 'object of the interfaces'
factory.namedNode('https://foo.example') vs new rdfjs.NamedNode('https://foo.example')
victor felder
@vhf
(you could even const {namedNode} = require('@rdfjs/data-model') and not use the factory object)
Austin Wright
@awwright
@elf-pavlik Well typically if you call a constructor as a function it returns a new instance of itself; String("foo") is functionally the same as new String("foo")
victor felder
@vhf
Looking at https://www.w3.org/TR/IndexedDB-2/#factory-interface , the fundamental difference is that IndexedDB is supposed to be implemented by browsers (it's a browser API, not a JS one), that's why it's accessible on window. I might be missing your point though
Austin Wright
@awwright
Though personally, I prefer the new form because it's more transparent to the developer about what's going on (it's probably going to generate a new instance of that interface)
victor felder
@vhf
Note that new String('foo') and String('foo') are different
elf Pavlik
@elf-pavlik
store.match(null, null, new NamedNode('https://foo.example/bar'))
vs
store.match(null, null, namedNode('https://foo.example/bar'))
victor felder
@vhf
> new String("foo")
[String: 'foo']
> String('foo')
'foo'
> String('foo') === String('foo')
true
> new String('foo') === new String('foo')
false
> String("foo") === 'foo'
true
> new String("foo") === 'foo'
false
Austin Wright
@awwright
I see
elf Pavlik
@elf-pavlik
actually I find that new inconvenient if one created instance somewhere else than when declaring variable
Austin Wright
@awwright
I've actually implemented IndexedDB on Node.js and submitted implementation feedback, Since then IndexedDB 2 was released; but note that the factory is producing objects anchored to some origin; the same way document.createElement() creates elements anchored to some document
Also it's a bit more careful in how it defines the interface; note it's using partial interface
elf Pavlik
@elf-pavlik
I haven't dive too deep in WebIDL but possibly we might want to use partial interface since we expect implementations to extend them
@awwright maybe you can suggest fix for ReSpec error visible on top right in https://rdf.js.org/stream-spec/

Failed to parse WebIDL: Syntax error at line 7, since interface Store: Store implements Source; ^ Unrecognised tokens.

I think implements got deprecated in WebIDL

Austin Wright
@awwright
@elf-pavlik Yeah, I'm no expert but I'd be happy to look into it
victor felder
@vhf
We might also want to use [NewObject] https://www.w3.org/TR/WebIDL-1/#NewObject
elf Pavlik
@elf-pavlik
but I don't think we can define Sink and Source as mixin since they have direct implementations
I agree that WebIDL definitions may need some polishing, if you have specific suggestions I think PR would work best to get them in
Eric Prud'hommeaux
@ericprud
@bergos, i see your name on the rdfjs/dataset-spec@85d6e3b commit to the dataset spec.
Eric Prud'hommeaux
@ericprud
was the intention that?:
  1. Both this and the argument are mutable datasets.
  2. Both this and the argument will have blank node labels rewritten per RDF Dataset Normalization. These changes will result in datasets that are graph isomorphic to the originals.
  3. Apart from blank node rewriting, no other changes, e.g. .add() or .delete(), will occur in these datasets.
Eric Prud'hommeaux
@ericprud
One commitment I'm looking for is whether a caller can count on .equals() performing normalization. .toCanonical() appears not to canonicalize the supplied graph, merely supply a string representation of a canonicalized copy of it.
victor felder
@vhf
The intention is that the argument should be treated as an immutable dataset. It would be impractical to require implementations to enforce this, hence these notes: https://rdf.js.org/dataset-spec/#dom-dataset-equals
I think this discussion is relevant to your question: rdfjs/dataset-spec#23
victor felder
@vhf
That part of the spec is still WIP, any input is welcome on this. My implementation of equals compares the toCanonical version of both but this might change. toCanonical doesn't canonicalize the graph, that's correct, similar to toString
Eric Prud'hommeaux
@ericprud
so in your implementation, there's no apparent rewriting of bnode labels in either this or the argument?
victor felder
@vhf
I think toCanonical does rewrite bnodes, it uses https://github.com/digitalbazaar/rdf-canonize under the hood
Eric Prud'hommeaux
@ericprud
If rdf-canonize() makes a new canonical copy of the original, calling .toCanonical() won't modify the argument; so that argument can be thought of as immutable.
victor felder
@vhf
Yes, that argument should be thought of as immutable. This is why we added these notes making implementers aware that they should think of the argument as immutable.
Eric Prud'hommeaux
@ericprud
but the .equals() text sort of overrides that by suggesting bnode rewrite
i'm trying to figure out the details of the current plan for .equals(), to the extent those details have been considered.
victor felder
@vhf
I see your point now, I agree it could be made clearer. This: Blank Nodes will be normalized. should be taken as Copies of this and the argument will be compared after blank nodes normalization, the normalization shouldn't be applied to the originals, they shouldn't be modified.
Let's try to make the final version better than the WIP once we agree on what exactly .equals should compare
Eric Prud'hommeaux
@ericprud
sounds good. i weighed in on that as well. tx for the pointer
Austin Wright
@awwright
Why does RDF Dataset Normalization apply to us? Two bnodes can have the same label and still be different bnodes.
Or more specifically, bnode labels are a property of the media type, if any are defined at all. [ ] is an example of an unlabeled bnode in Turtle. The label doesn't exist in RDF proper, and since RDFjs isn't a serialization, I'm not sure it makes sense to have process-wide bnode labels.
Eric Prud'hommeaux
@ericprud
The RDF spec documents how the outside world should interact with RDF graphs. The practical programmer interface can be much more intimate.
Eric Prud'hommeaux
@ericprud
I believe that not having bnodes in the process would mean you can't use bnodes. If you get a quad with a bnode back from getQuads(), you expect to be able to identify that bnode in subsequent getQuads(), removeMatching(), addAll(), etc
otherwise, getting a bnode back would basically be a dead end.
Austin Wright
@awwright
New version of "rdf" out with Dataset, Quad, factory, Graph#simplyEntails, TermMap, PrefixMap, and several improvements: https://yarnpkg.com/en/package/rdf
Please test and submit feedback :)
elf Pavlik
@elf-pavlik
:clap: :clap: :clap:
Angelo Veltens
@angelo-v
Hi, I am trying to use fetch-lite in a browser environment. What I got from the readme it is meant to work there.
Unfortunately I am getting an error, because the finished imported here from readable-stream is undefined.
finished is somehow not exported in the browsers version, see https://github.com/nodejs/readable-stream/blob/master/readable-browser.js
cc @bergos
Tomasz Pluskiewicz
@tpluscode
would be nice if you could share a stackblitz or smth which reproduces the problem
readable-stream is yet another package? how are you serving your code? webpack?
Angelo Veltens
@angelo-v
yep tested with webpack dev server so far, I could prepare an example, just wanted to be sure that this is nothing obvious