Re: RDF being phased out?

neil.stansbury () redbacksystems ! com wrote:
> 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.

I still haven't fully digested this, maybe IDLs would help, yeah.

>> 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)

I think that the resolution to this right now is WONTFIX, mostly due to 
the fact that it's just hard to get the versioning right. Maybe there's 
room in Mozilla2 to improve on this, but I don't know if anybody had 
assigned tasks in that direction.

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

I think that the fact that most folks end up writing wrappers around the 
API is a clear indication that the API sucks.

That doesn't mean that there wouldn't be interesting things to do on top 
of it, just that the API ain't well.

Axel