Talk:RDF:Interfaces

Peter Wilson: Some notes on current shortcomings:

• 1. Ensure all rdf nodes have a value property. Its a pita to have ValueUTF8, Value etc.

I'll take a mental note on this one.

• 2. rdfINumber JS compatible decimal number. (Possibly replace nsIRDFInt)
• 3. rdfIBoolean JS compatible boolean.

Those are for later. Replacing ints is not going to happen. No idea what "js compatible" should mean, though.

• 4. rdfIService.findResource(string)->bool should actually exist. (see 5.) A better name would be hasResource (It doesn't actually find anything).

Useless. Whether any datasource has a particular resource doesn't have a single use case. (The RDF Service is globally unique, or, a singleton.)

PW The Help system uses synthesised Resource names (based on user input) to perform searches and index operations. The global creation of those resources could be avoided by an existance check. i.e RDF.hasResource(NC:index + "#" + userTerm) instead of RDF.GetResource and DS.HasAssertion. If there is no resource there is no point looking in the datastore for the definition.

• 5. Is there any way to implement a case insensitive version of getSources?

Yes, by hand.

PW No there isn't. If I have a user entered string, matching it against a case variant of that string will take 2**N HasAssertion operations where N is the length of the string.

• 6. Are rdf:type and xml:lang handled correctly, at all?

Not yet, but at least for rdf:type, there is a bug on file. I know about xml:lang.

• 7. getDataSource should throw an exception if the source does not exist. Currently an empty DS is returned.
• 8. OR, A way to check that a datasource exists without creating it as a by-product.

That is a feature, not a bug. But it may happen that we completely drop the rdf service for this.

• 9. JS Access to the blob type. Other API manage to handle byte objects. Together with 6. you would be able to implement any xsd or user defined type - but better to use XPCOM interfaces for each type.

Which APIs?

• 10. Access to facts via the pattern (Subject ?Predicate Object). Currently, you have to do ArcsOut and test for the Object. Call it getPredicates. (see 5.)

Not going to happen, this is a pretty rare usecase. At least so far, and we're not going to make it performant. That would mean that we had to update a third hashtable for all operations which would result in an overall performance decay. Veto from my side.

• 11. You already know about the rdf parser error handling.
• 12. Call the new string literal rdfIString (Numbers are literals as well). Reserve the term literal as a generic term for non-resources.

I'll take a mental note.