Gianugo Rabellino wrote:
> I'm sure about that, and, just in case, please note that I didn't
want
> to sound harsh, I was just trying to be constructive. :-)
Don't worry. No offense taken :-)
>
>>
>> I'm however cautious about breaking SourceDescriptionGenerator,
more
>> so that I found that the slide block isn't marked unstable (Is it
too
>> late to change this?).
>
> I guess we should ask Stephen about it, but I'd be +1, since Slide
> itself is unstable.
+1
>
> Do we have a deal then with something like the following?
>
> <source:props> <!-- plural is better IMO -->
> <dav:getcontenttype>text/xml</dav:getcontenttype>
> <my:author>Me, Myself and I</my:author>
> <his:foo>
> <his:bar>baz</his:bar>
> </his:foo>
> </source:props>
+1
>
> Implementing this scenario should be fairly easy. startRecording()
on
> source:props startElement(), endRecording() on endElement(); then
get
> the resulting DocumentFragment and for each child set a
SourceProperty
> using that Element. How does it sound?
>
>> 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?
> Actually it would be
> pretty simple to refactor it in a more generic way, passing from an
> Element to a Node which might be a text node in case of simple
string
> properties. But again, this is not the case for now.
>
>> Yes, I know. See above.
>> However I would prefer to defer the XML handling of property
_values_
>> to the WebDAVSource and have the SourceProperty class be neutral to
>> XML.
>
> The problem is that it's not XML neutral already. :-/ Value is an
> Element as of now.
>
>> 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.
Guido
