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