A value of a property however doesn't necessarily has to be XML. Especially if you think of other Sources besides WebDAVSource.
This is, however, the case of the current SourceProperty, a contract that, as of now, we might not want to break.
I think we have to. For example in:
public SourceProperty(Element property) { this.namespace = property.getNamespaceURI(); this.name = property.getLocalName(); this.value = property; }
the whole element is set to the value which might not be what you want above. It might even be convenient for WebDAVSource but don't we want to make sure InspectableSource supports sources without XMLized properties?
Definitely. Problem is understanding use cases. Apart from the upcoming Xindice (*not* XML:DB as of now), I can't think of any other Source that allows write access to properties, so we might just be trying to generalize something that is really webdav-specific. On the contrary, though, almost every source comes with a set of "live properties" and it would be nice to be able to describe them (think of size, content-type, lastmodified). But this is a read-only scenario.
This said, I'd +1 a modification of SourceProperty so that value is a string (which could well be serialized XML). A better solution might be turning SourceProperty into an interface, so that a specialized WebDAVSourceProperty might use the added value of XML, (de)serializing it when needed. I'd suggest to wait for Sylvain to show up: I recall him having some thoughts on it.
It feels a bit like mixing concerns to me (setting properties and writing content).
I don't think so. It makes sense for metadata to be written together with data (and being manipulated separately if that's the case), what's wring with it?
Some may want to put their meta data in a SQL DB. That's what I would do in case of lack of DASL support on the WebDAV server side. And I like it being more explicit where my meta data go. But I'm +/-0 to merge SWPT with SWT.
On second thought I think you're right. Having two separate SourceWriter might allow far more flexibility: in fact they could be easily configured one after the other in the pipeline (and with the upcoming virtual components we might end up with something that just looks as a single one). I'm somehow bothered by the fact that data and metadata need to be sibling, like in
<source:write>
<document>
blah
</document>
</source:write><meta:write> <author:myself/> </meta:write>
since
<source:write>
<source:meta>
<author:myself/>
</source:meta>
<document>
blah
</document>
</source:write>looks IMO much better. But I can live with that. :-)
Ciao,
-- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Now blogging at: http://blogs.cocoondev.org/gianugo/)
