RDF recap
rvj
Having to redesign an application almost entirely based on RDF with
something else is no small feat.
I understand the reason to pull the API, but my interest is in non API
support within xulrunner
As I'm particularly hard of hearing, some of the earlier explanations have
left me scrathing my head
particularly when it comes to the preservation of <seq> ordered lists using
the local file system
1. I guess the most obvious question is how to provide the equivalent of
the <tree/> widget which I
assume will go ?
2. My guess is that the template generator can produce something
approximating to to a HTML tree view from an RDF datasource?
3. I assume that template generator will continue to support composite RDF
datasources ?
4. Is there any chance of the template generator being able to reflect
changes back into the RDF datasource
The idea here is that we can apply DOM methods on the generated html which
will automatically reflect any changes back to the approriate datasource via
the "ref" (dynamic template)
The alternative I guess is to perhaps create some kind of output parser
(xsl) whish will take the generated html and
re-build an updated RDF file (the equivalent of flush() )
Are any of the above assumptions correct?
Axel Hecht
> Having to redesign an application almost entirely based on RDF with
> something else is no small feat.
> I understand the reason to pull the API, but my interest is in non API
> support within xulrunner
>
> As I'm particularly hard of hearing, some of the earlier explanations have
> left me scrathing my head
> particularly when it comes to the preservation of <seq> ordered lists using
> the local file system
>
> 1. I guess the most obvious question is how to provide the equivalent of
> the <tree/> widget which I
> assume will go ?
XUL templates are not bound to RDF anymore since at least 1.9, but I
think in gecko 1.8.1, too. In particular, I haven't seen anybody
proposing the death of templates, but the RDF template engine (as one of
the options) will likely die or have to move elsewhere.
> 2. My guess is that the template generator can produce something
> approximating to to a HTML tree view from an RDF datasource?
Without an RDF datasource, that'll be tough.
> 3. I assume that template generator will continue to support composite RDF
> datasources ?
That sentence has "RDF" in it, so no.
> 4. Is there any chance of the template generator being able to reflect
> changes back into the RDF datasource
You're starting to sounds weird.
> The idea here is that we can apply DOM methods on the generated html which
> will automatically reflect any changes back to the approriate datasource via
> the "ref" (dynamic template)
>
> The alternative I guess is to perhaps create some kind of output parser
> (xsl) whish will take the generated html and
> re-build an updated RDF file (the equivalent of flush() )
>
> Are any of the above assumptions correct?
None, and I have no idea where you get them from.
Axel