I am however a bit uncomfortable with the current implementation and
I'm uncomfortable with the current approach as well (it's work in progress :-). That is primarily due to the current design and implementation of (the seemingly unfinished) SourceProperty class. Changing this was next on my list (as was discussing SourcepropsWritingTransformer's input XML :-).
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. :-)
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.
I felt like seperating the property namespace from the XML namespaces
was a good idea, since it would be an easy way to deal with
InspectableSource implementations that don't deal with namespaced
properties.
I don't think that, even after the possible refactoring of InspectableSource, all SourceProperties should be namespaced. It makes very little sense today not to use namespace for properties: in case there is no need for a namespace it would be pretty easy to add a convenience one and preserve both ease of use and rich properties.
On a second thought an alternative would be to have only one <source:prop> element and have all immediate children be the properties.
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>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. 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?
Currently the only requirement SourceWritingTransformer has is the Source to be modifiable. You would need to have a look at SWT's input XML to know which pseudo protcols can be used with it.
It can easily remain so. Just if( source instanceof InspectableSource) and you can have a perfectly backward compatible SWT...
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/)
