RDF being phased out?
Fernandez, Sylvester J
I hear that use of RDF will be phased out in the future. Where can I
find out more about this development?
Thanks.
Sylvester
Axel Hecht
> Hi,
>
> I hear that use of RDF will be phased out in the future. Where can I
> find out more about this development?
>
It depends. There are various different usages for RDF. Templates would
be one, the docs for the new stuff for that are on MDC. Then the stuff
that mailnews does wrt to RDF in Addressbook and friends, the rip out of
that is part of the tb 3 design plan.
Basically, RDF is phased out, but still used all over, so we're
gradually moving over to not using it. That isn't really an overall
plan, but more of an agenda, that's happening at the pace of the
particular code pieces.
Axel
rvj
just when I thought things were pretty stable....
any reasons why RDF to be phased out .... and what will replace it?
"Axel Hecht" <ax...@pike.org> wrote in message
news:IMadnQFSkdq6-mja...@mozilla.org...
Axel Hecht
> just when I thought things were pretty stable....
>
>
> any reasons why RDF to be phased out .... and what will replace it?
>
There are design bugs in our impl, and the impl never caught up with any
RDF standard, so we have a few bugs that are incredibly hard to fix, and
a plethora of not-backwards compatible changes to get the RDF testsuites
to pass.
The first bucket wasn't tackled before we phased RDF out, the latter is
hard to do without.
As for replacements, people like sql and json.
Axel
rvj
still hoped that Mozilla's RDF would offer an alternative approach to the
redundancy of SQL field duplication
In fact my main concern over the last couple of years has been whether RDF,
or the template generator would be able cope with normal CSS styling (I
still dont know how style the currently selected item in a listbox with
selected item icon).
Ive belated discovered how to do this but its not exactly been apparent
through Mozilla documentation.
Am I correct in thinking that the equivalent of RDF flush() is now
officially available in Mozilla for XML files
(presumably SAVE) ?
"Axel Hecht" <ax...@pike.org> wrote in message
news:Pf2dnaW-OJwThWva...@mozilla.org...
rvj
a) does that mean that all RDF support say in XULRunner will be removed or
will it be frozen?
b) if frozen will the bugs that remain be avoidable if well documented ?
"rvj" <r...@rolemodels.net> wrote in message
news:qIudnfm0fMdVymfa...@mozilla.org...
Axel Hecht
> final question (s)
>
> a) does that mean that all RDF support say in XULRunner will be removed or
> will it be frozen?
> b) if frozen will the bugs that remain be avoidable if well documented ?
Phased out means killed, and stuffed with a gym sock.
Axel
Neil
> As for replacements, people like sql and json.
Not that these replace RDF as such; to "upgrade" existing applications
you'll still have to rewrite all your back-end code.
--
Warning: May contain traces of nuts.
Unknown
> It depends. There are various different usages for RDF. Templates would
> be one, the docs for the new stuff for that are on MDC. Then the stuff
> that mailnews does wrt to RDF in Addressbook and friends, the rip out of
> that is part of the tb 3 design plan.
>
> Basically, RDF is phased out, but still used all over, so we're
> gradually moving over to not using it. That isn't really an overall
> plan, but more of an agenda, that's happening at the pace of the
> particular code pieces.
>
> Axel
I have to say personally I think this is nothing short of a travesty.
Although eclectic, RDF is a superb tool for many data apps and achieves things that JSON and SQL will never be able to.
1. Is there a definitive time scale when we'll lose RDF support in Mozilla - specifically XULRUnner?
2. Does anyone know of any other Open Source RDF impl that might be able to replace the existing XPCOM one?
Cheers,
N
Axel Hecht
> Axel Hecht wrote:
> > It depends. There are various different usages for RDF. Templates would
>> be one, the docs for the new stuff for that are on MDC. Then the stuff
>> that mailnews does wrt to RDF in Addressbook and friends, the rip out
>> of that is part of the tb 3 design plan.
>>
>> Basically, RDF is phased out, but still used all over, so we're
>> gradually moving over to not using it. That isn't really an overall
>> plan, but more of an agenda, that's happening at the pace of the
>> particular code pieces.
>>
>> Axel
>
> I have to say personally I think this is nothing short of a travesty.
>
> Although eclectic, RDF is a superb tool for many data apps and achieves
> things that JSON and SQL will never be able to.
>
> 1. Is there a definitive time scale when we'll lose RDF support in
> Mozilla - specifically XULRUnner?
No, at least I haven't heard of one.
> 2. Does anyone know of any other Open Source RDF impl that might be able
> to replace the existing XPCOM one?
RDF impl is the least thing. A savvy API? Played with that on
http://hg.mozilla.org/users/axel_mozilla.com/index.cgi/rdf2/file/tip.
The backend? Didn't mind too much, and it really makes sense to tune it
to the API. An RDF/XML parsing/serialization framework? Turtle?
Ntriples? Yet another thing.
And of course, should the templates you're used to work on that engine?
Or at least migrate nicely?
What I'm trying to say, RDF is an almost as overloaded term as Mozilla
is, so you should specify what you really want.
Axel
Unknown
I guess at the very least I just want it as it is!
Personally, I don't have any issues with the current RDF API at all - once mastered it works brilliantly - period. I think you've done a great
job on it. Heck we can run and display a regex filter over a 100,000 child XUL tree built from a wrapped JS DS in about half a second! You'll
get no complaints here.
From an API point of view, we've abstracted all the RDF API stuff anyway into our own generic Object API that hides all the RDF
resources/literals/arcs etc and tracks which DS an assertion exists in. Eg:
var res1 = new Resource( STRINGURI_1 );
var res2 = new Resource( STRINGURI_2 );
var attr = res1.createAttribute( STRINGURI_3 )
attr.value = "Something";
res2.appendAttribute( attr );
[or]
attr.setLiteral( XMLSChemaTypeObject, Language ) // ANYURI is assumed to be an RDFResource
So we're already pretty abstracted from any potential RDF API changes. My only longterm request would be xml:base and schema.
For the record - we have just had our _entire_ application borked because Mozilla decided to drop native SOAP support in 1.9, I'd much rather
have a slightly broken and eclectic API than none at all. I've just wasted 5 weeks of my life writing an entire SOAP API for all our stuff - I
don't fancy doing that to get back RDF support as well. Give me some bust XUL templates any day!
Just wanted to say, if nothing else - I'm feeling the RDF love.
N
Axel Hecht
> Hey Axel,
>
> I guess at the very least I just want it as it is!
I'm afraid that's the last thing you'll get.
> Personally, I don't have any issues with the current RDF API at all -
> once mastered it works brilliantly - period. I think you've done a great
> job on it. Heck we can run and display a regex filter over a 100,000
> child XUL tree built from a wrapped JS DS in about half a second! You'll
> get no complaints here.
>
> From an API point of view, we've abstracted all the RDF API stuff
> anyway into our own generic Object API that hides all the RDF
> resources/literals/arcs etc and tracks which DS an assertion exists in. Eg:
>
> var res1 = new Resource( STRINGURI_1 );
> var res2 = new Resource( STRINGURI_2 );
> var attr = res1.createAttribute( STRINGURI_3 )
> attr.value = "Something";
> res2.appendAttribute( attr );
> [or]
> attr.setLiteral( XMLSChemaTypeObject, Language ) // ANYURI is assumed to
> be an RDFResource
>
>
> 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?
>
> For the record - we have just had our _entire_ application borked
> because Mozilla decided to drop native SOAP support in 1.9, I'd much
> rather have a slightly broken and eclectic API than none at all. I've
> just wasted 5 weeks of my life writing an entire SOAP API for all our
> stuff - I don't fancy doing that to get back RDF support as well. Give
> me some bust XUL templates any day!
>
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.
>
> Just wanted to say, if nothing else - I'm feeling the RDF love.
That'd be you, and you, and .... err .... you. Already 3 :-)
Axel
Unknown
> 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
Axel Hecht
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
mixit
(
I understand that there may well be cruft problems associated with
legacy code but
RDF represents an incredibly useful tool, especially when combined
with the template builder.
I'm lead developer on a 4 year project that has been using XUL for an
in-house application
and we rely utterly on RDF and the template builder to manage our huge
data structures.
Is there any possibility of finding the resources for keeping RDF
going or updating the legacy code
to solve the long-running issues? (Perhaps in the form of support from
my customer?)
si
Axel Hecht
The template builder isn't going away.
What Mozilla 2 at large will mean for your application is going to be an
interesting question. JS code should hopefully port easily, but that may
well depend on what you're doing.
As I've mentioned before, there isn't a clear definition of RDF, I
suspect that different folks want different things. Like, to me, RDF is
a dynamically typed aggregated directed labeled graph, and RDF/XML is a
bug. I've seen other opinions, too.
That makes "keep my stuff working" an underdefined request, sadly. And,
honestly, Mozilla 2 is really just about "no, not that, sorry". We're
not doing that with evil intentions, but in the interest of the
platform, and there is plenty of heads-up notice now for you guys to
figure out what of RDF you really used and if it was really more than
just the stuff that was available back then.
Axel
Unknown
> As I've mentioned before, there isn't a clear definition of RDF, I
> suspect that different folks want different things. Like, to me, RDF is
> a dynamically typed aggregated directed labeled graph, and RDF/XML is a
> bug. I've seen other opinions, too.
Axel, by RDF/XML do you mean the document format?
If so I quite agree - the [immense] value we get from RDF is the
aggregated graph. All our triples are being stored in SQLite anyway so
the document format to us is irrelivant. Though I had assumed
manipulating the triples would be the hard part rather tha parsing an
XML doc.
N
kristo...@gmail.com
> Axel, by RDF/XML do you mean the document format?
>
> If so I quite agree - the [immense] value we get from RDF is the
> aggregated graph. All our triples are being stored in SQLite anyway so
> the document format to us is irrelivant. Though I had assumed
> manipulating the triples would be the hard part rather tha parsing an
> XML doc.
>
> N
I wholeheartedly agree with that statement as well. I'm new to
Mozilla (been working with it for 6 months), and before being exposed
to Mozilla's RDF implementation I was trying convoluted ways of making
my flat file and RDBMS systems behave like the RDF specs. The whole
concept breaks us free of tables and columns, a big step forward for
data query and manipulation. Send RDF/XML to the yard sale as far as
I'm concerned, but the whole idea of an infinite range of nodes and
links cannot be stuffed in the trash, lest we step back in time with
XML or something... XML data stores are not really an improvement over
RDBMS and SQL. (SOAP was a waste of time).
Yes, Mozilla's API's are rubbish, but they were ahead of their time...
What do we expect. Can the API's be redone in Mozilla 2? If not, I'd
rather keep using my wrappers than give it up entirely.
--Kris
sebwin
> Mozilla (been working with it for 6 months), and before being exposed
> to Mozilla's RDF implementation I was trying convoluted ways of making
> my flat file and RDBMS systems behave like the RDF specs. The whole
> concept breaks us free of tables and columns, a big step forward for
> data query and manipulation. Send RDF/XML to the yard sale as far as
> I'm concerned, but the whole idea of an infinite range of nodes and
> links cannot be stuffed in the trash, lest we step back in time with
> XML or something... XML data stores are not really an improvement over
> RDBMS and SQL. (SOAP was a waste of time).
>
> Yes, Mozilla's API's are rubbish, but they were ahead of their time...
> What do we expect. Can the API's be redone in Mozilla 2? If not, I'd
> rather keep using my wrappers than give it up entirely.
I just want to manifest my RDF love. (Now we're four!)
I don't even mind RDF-XML, in spite of XML verbosity.
The API I've wrapped too, so yeah, that part could use a complete
revamping in my opinion.
But, fundamentally, resource graphing is immensely powerful and also
very elegant when comparing with SQL, for example.
It is definitely worth preserving and improving!
-Sebastian