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.

Joe Foo on the web loads another RDF/XML datasource that uses that resource and breaks your search? Nice. Sounds like a bug in your scheme, of some sort.

• 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.

How does adding an API reduce numerical complexity? Stop requesting miracles that are not going to be used anywhere. Or that are merely bugs elsewhere. If this is still about search, you do case-conversion and dummy word removal before searching, not afterwards.

• 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.

visit return type

Enn: rdfITripleVisitor.visit should just return true or false to continue iterating rather than using an incomprehsible system of error codes. In fact, I don't even know how I would get such a return code from JS.

I'll document how to get there from JS. Using bool return values is just extra-cumbersome from C++, and we need to handle errors anyway.

Preview docs:

Components.returnCode = Components.results.NS_RDF_STOP_VISIT;

though the exposure of RDF return codes isn't done yet. I had to find out how to do that, that would be useful in general. --AxelHecht 01:46, 16 Jun 2005 (PDT)

Enn: huh? The goal is to make the lesser used C++ less cumbersome yet make the more common JS usage more cumbersome? That makes no sense.

Well, most of the time, the visit code will not bother about iteration, isn't a "you have to return true to make it work" more cumbersome? I don't like the idea of having two ways of stopping iterations, either, as you could still throw an exception or return false. I'm really not digging that. --AxelHecht 08:00, 16 Jun 2005 (PDT)