Re: RDF being phased out?

Axel Hecht wrote:
> neil.stansbury () redbacksystems ! com wrote:
>> I guess at the very least I just want it as it is!
> 
> I'm afraid that's the last thing you'll get.

Upgrades/Changes/Borked templates fine - my only concern here is any more complete Mozilla "Rug Pulling" ;-)

>> So we're already pretty abstracted from any potential RDF API 
>> changes.  My only longterm request would be xml:base and schema.
>>
> 
> Interesting. Are you doing anything on the query side of life?

Well not XQuery but yeah.  We have abstracted RDF datastores into what we call Cachestores to which we apply a "Scope" to control what it 
publically asserts.  A "Scope" is just one of our generic resource objects I mentioned before, with a bunch of arbitrary attribute/values. The 
Cachestore regexes the attribute/values in the DS and returns a wrapped nsISimpleEnum.  So the "query object" is in reality just a bunch of arcs 
that can exist in any DS.
Eg.

var res = cachestore.getResource( STRING_URI );
var attr = res.getAttribute( dc:source );
var scope = new Resource() // Anonymous
scope.appendAttribute( attr );
var enum = cs.getResourcesInScope( scope ); // Returns all resources in that CS/DS that match the scope

Multiple attributes can be asserted in different CS(DS) but presented as a single aggregate resource object.

var cs = resource.getAttribute( dc:title ).getOwner().getCachestore();

Means we can find the CS(DS) the arc really exists in etc. This was the only way I could figure to keep track of assertions once they were "in 
the wild" to quote yourself.

Happy to fire the IDLs over if of any interest.

> Disclaimer upfront, I'm not doing RDF as my main objective, so I don't 
> know if I'll be in charge of anything backwards compat here.
> 
> I really don't know what the exit path should be here. I guess for some 
> use cases, some jsm or a component would suffice.
> 
> On the other hand, do we really need to re-implement all the 
> historically grown cruft in our rdf template engine? That's kind-of the 
> problem of rdf, there are so many things which could be prettier, just 
> if it wasn't for the folks actually using the status quo. And Mozilla 2 
> is the designated place to fix those.

I know this isn't the right NG but IMO, this demonstrates that long term Mozilla should be spitting the XPCOM stuff into their own separate XPIs.

Perhaps the way Neil did on the XULPlanet XPCOM ref page.  That way we could say install RDF.XPI, WEBSERVICES.XPI, LDAP.XPI etc then we just get 
the most recent binary build of that set of components.  Updates etc could work like anyother XPI.  Then I can install the old RDF.XPI and the 
compatible XBL.XPI or RDF2.XPI and XBL2.XPI etc etc.

It would certainly make installing a XULRunner app a breeze - just pick the XPCOM stuff you need.  No need to break or drop anything. (Though I 
don't know the CPP source anywhere near well enough to make any informed statement of how tricky this is)


>> Just wanted to say, if nothing else - I'm feeling the RDF love.
> 
> That'd be you, and you, and .... err .... you. Already 3 :-)

Thought it was feeling a little lonely round here ;-)

Though perhaps if reading the RDF spec didn't make you want to blown your own brains out more people might be getting loved up over it.  Mind 
you I guess the whole Mozilla API is miles ahead of anything else so these things do take time to catch on.


Cheers,

N