Guido Casper wrote:
>>>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/)
|