SourcepropWritingTransformer

[Gianugo Rabellino <gi...@apache.org>]

I'm about to tackle WebDAV properties handling, and I was happy to find 
that Guido has already provided something. :-)

I am however a bit uncomfortable with the current implementation and I 
wanted to see if it's just me not having the correct approach.

A source property (both in webdav sense and in the  SourceProperty 
implementation) is made of three part: a local name (String), a 
namespace (String) and a value (DOM Element). It's worth noticing that 
the property value is actually the *holder element* plus it's value 
(that is a text node - in case of a string value - or other Elements), 
so that effectively you get, in case of webdav,

<getcontenttype xmlns="DAV:">text/xml</getcontenttype>

a property name of "getcontenttype, a namespace of "DAV:" and a value of 
(xml-ized)
<getcontenttype xmlns="DAV:">text/xml</getcontenttype>. User space tools 
will then give you a value of "text/xml", but this is a different issue.

All this said, I fail to understand why this transformer is somehow 
reinveinting XML by using this syntax:

<source:prop name="author" namespace="meta">me</source:prop>

which forces, besides, to use a very risky solution to rebuild the property:

   String pre = "<"+name+" xmlns="+quote+namespace+quote+">";
   String post = "</"+name+">";
   String xml = pre+value+post;
   StringReader reader = new StringReader(xml);
   Document doc = parser.parseDocument(new InputSource(reader));
   SourceProperty property = new SourceProperty(doc.getDocumentElement());
   ((InspectableSource)source).setSourceProperty(property);

One of my biggest no-no is not to use string manipulation to build XML: 
this algo would fail in case the element has any XML reserver characters 
or is an XML property value with nested elements.

What about using good 'ole XML instead? I'm considering something like:

   <source:props>
      <myns:author xmlns:myns="meta">me</myns:author>
   </source:props>

This would allow using standard Transformer tools (startRecording() 
instead than startTextRecording()) to set the properties later. It would 
be much safer and a good bit more XMLish (and WebDAVish too). Also, this 
modification could be inserted directly into the 
SourceWritingTransformer without requiring a new transformer just to set 
properties.

How does it sound? Am I overlooking something?

-- 
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/)

Re: SourcepropWritingTransformer

[Guido Casper <gc...@s-und-n.de>]

Gianugo Rabellino wrote:
> 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

Well, I already thought of something like an inspectable file source
where (switching to wild mode) the inspectable part might be something
like an aspect. That way you can "inspect-enable" (can you say
webdav-enable? :-) Ok, then again you have to deal with XMLized
properties) any modifiable source, like CVSSource. The user defines
where he wants the meta data to go. This could be as simple as
seperate files with a .meta extension or a SQL DB or whatever.

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

Yes, if I remember correctly (although my memory served me bad lately
:-) he was in favour of eliminating the indirection  through the
SourceProperties class alltogether.

However I think the flexibility provided through SourceProperty could
be of value.

Guido

Re: SourcepropWritingTransformer

[Gianugo Rabellino <gi...@apache.org>]

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/)

Re: SourcepropWritingTransformer

[Guido Casper <gc...@s-und-n.de>]

Gianugo Rabellino wrote:
> Guido Casper wrote:
>
>> However concerning interface design I think if you give the
following
>> input to SPWT:
>>
>>     <source:props>
>>       <my:author xmlns:my="my">Me, Myself and I</my:author>
>>     </source:props>
>>
>>
>> One would expect that
>>
>>       WebdavSource.getSourceProperty("my", "author").getValue();
>>
>> returns:
>>
>>       Me, Myself and I
>
> Yes, I see your point. It would be easy to get the value as a
string,
> but what happens if value is an XML fragment? I'm wondering if it's
> safe to assume that if you call getPropertyValueAsString you know
> what you're doing so that you know that there will be no nested XML.
> I'm also thinking about dealing separately with the two cases, so
> that when value is just element + text node return just the text
> node, and return the (String) XML representation otherwise so that
>
> <my:author xmlns:my="my">Me, Myself and I</my:author>
>
> returns
>
> Me, Myself and I
>
> and
>
> <my:author xmlns:my="my">
> <my:firstname>Me</my:firstname>
> <my:lastname>Myself and I</my:lastname>
> </my:author>
>
> returns the untouched XML. Is that overcomplicated?

I would vote now to leave SourceProperty as it is (except fixing
the setValue(String value) method) and cleanup
WebDAVSource.getSourceProperty/ies() with (something like):

    return new SourceProperty(prop.getElement());

InspectableSource implementations without XMLized properties would
have to serialize the XML themselves (in a way they want it to be).
Actually that is what you would have to do then in
WebDAVSource.setSourceProperty() (serializing the XML) since the
WebDAVResource class (of the slide lib) only supports setting
properties via Strings (it's a bit inconsistent in this regard).

But that way you can easily switch SPWT from startTextRecording() to
startRecording().

WebDAVSource.getSourceProperty() also needs to be changed to request
only the wanted property from the WebDAV server and not all
properties.

Another thing we have to agree on is the namespace of SPWT which
currently is:
http://apache.org/cocoon/propwrite/1.0

and of course the name of SourcepropsWritingTransformer itself :-)

Guido

Re: SourcepropWritingTransformer

[Gianugo Rabellino <gi...@apache.org>]

Guido Casper wrote:

> However concerning interface design I think if you give the following
> input to SPWT:
> 
>     <source:props>
>       <my:author xmlns:my="my">Me, Myself and I</my:author>
>     </source:props>
> 
> 
> One would expect that
> 
>       WebdavSource.getSourceProperty("my", "author").getValue();
> 
> returns:
> 
>       Me, Myself and I

Yes, I see your point. It would be easy to get the value as a string, 
but what happens if value is an XML fragment? I'm wondering if it's safe 
to assume that if you call getPropertyValueAsString you know what you're 
doing so that you know that there will be no nested XML. I'm also 
thinking about dealing separately with the two cases, so that when value 
is just element + text node return just the text node, and return the 
(String) XML representation otherwise so that

<my:author xmlns:my="my">Me, Myself and I</my:author>

returns

Me, Myself and I

and

<my:author xmlns:my="my">
	<my:firstname>Me</my:firstname>
	<my:lastname>Myself and I</my:lastname>
</my:author>

returns the untouched XML. Is that overcomplicated?

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/)

Re: SourcepropWritingTransformer

[Guido Casper <gc...@s-und-n.de>]

Gianugo Rabellino wrote:
> Guido Casper wrote:
>
>> Maybe having getValueAsString() not skipping non-text elements
>> (although I might not understand what the rationale for this
>> behaviour is) would be enough to support sources without XMLized
>> properties.
>
> Yes, probably. We'll need to discuss that some more, I was hoping
that
> Stephan would show up and join the party...

Ah, I think SourceProperty is modeled after the slide client webdav
lib's BaseProperty class, that skips non-text nodes in
getPropertyAsString() as well.

>
>
>> But I would also like to change SourceProperty.value to only hold
the
>> property child nodes. This would also simplify
>> WebDAVSource.getSourceProperties().
>
> What do you mean exactly? If a (WebDAV, agreed) property is an XML
> element this means that you might have to rebuild it anyhow, so what
> is the point?

Yes you are right.
Now understanding the above said however (SourceProperty is modeled
after the BaseProperty class) in WebDAVSource.getSourceProperty() you
simply could:

    return new SourceProperty(prop.getElement());


However concerning interface design I think if you give the following
input to SPWT:

    <source:props>
      <my:author xmlns:my="my">Me, Myself and I</my:author>
    </source:props>


One would expect that

      WebdavSource.getSourceProperty("my", "author").getValue();

returns:

      Me, Myself and I


and not

      <my:author xmlns:my="my">Me, Myself and I</my:author>

But in order to not break what we have, we can leave it as it is and
make the above change to WebDAVSource.

Guido

Re: SourcepropWritingTransformer

[Gianugo Rabellino <gi...@apache.org>]

Guido Casper wrote:

> Maybe having getValueAsString() not skipping non-text elements
> (although I might not understand what the rationale for this behaviour
> is) would be enough to support sources without XMLized properties.

Yes, probably. We'll need to discuss that some more, I was hoping that 
Stephan would show up and join the party...


> But I would also like to change SourceProperty.value to only hold the
> property child nodes. This would also simplify
> WebDAVSource.getSourceProperties().

What do you mean exactly? If a (WebDAV, agreed) property is an XML 
element this means that you might have to rebuild it anyhow, so what is 
the point?

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/)

Re: SourcepropWritingTransformer

[Guido Casper <gc...@s-und-n.de>]

Guido Casper wrote:
> Gianugo Rabellino wrote:
>> 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?

Maybe having getValueAsString() not skipping non-text elements
(although I might not understand what the rationale for this behaviour
is) would be enough to support sources without XMLized properties.

But I would also like to change SourceProperty.value to only hold the
property child nodes. This would also simplify
WebDAVSource.getSourceProperties().

Guido

Re: SourcepropWritingTransformer

[Guido Casper <gc...@s-und-n.de>]

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

Re: SourcepropWritingTransformer

[Gianugo Rabellino <gi...@apache.org>]

Stephan Michels wrote:
> 
> My first approach was to combine the information of the directory
> struture, properties of the source(SourceProperty), and properties
> which would retrieve independently(SourceInspector). With the last
> one I want to make the serveral derivations of the the DirectoryGenerator
> redundant, like MP3DirectoryGenerator, ImageDirectory...
> 
> But I must admit that I neglected the KISS pinciple. Separating these
> things into serveral transformer is a better approach.

+1. It might be a little ankward from a sitemap perspective, but virtual 
components might help a lot here.

> 
> BTW, it's annoying getting every day 400 sorbig mails.
> 

400? You lucky boy. I'm getting 700+, and I have no way to protect from 
them on the server (my personal mail server upgrade is due on September 
:-/).

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/)

Re: SourcepropWritingTransformer

[Guido Casper <gc...@s-und-n.de>]

Stephan Michels wrote:
> On Tue, 26 Aug 2003, Gianugo Rabellino wrote:
>
>> Guido Casper wrote:
>>> 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.
>
> No doubts. All I wanted was to write an ultimative
DirectoryGenerator
> which the SourceDescriptionGenerator.

I liked the idea of SourceDescriptionGenerator. What would be nice is
to have it even more configurable in what kind of properties it
delivers (maybe via a list of property names).

<snip/>
> DircetoryGenerator -> Information of Sources
> SourcepropsWritingTransformer -> Getting additional properties
>
> This would make my way easier
>
> DircetoryGenerator
> SourcepropsWritingTransformer
> SourcePermissionsTransformer
> SourceLocksTransformer
> SourceInspectorTransformer
>
> -> all information, which one can need

I think a Generator for getting (any kind of) properties is more
suitable.

How about:

    <map:match pattern="dir/">
      <map:generate type="directory" src="dir/"/>
      <map:transform src="2cinclude.xsl"/>
      <map:transform type="cinclude"/>
      <map:serialize type="xml"/>
    </map:match>

and having CIncludeTransformer pointing to one or several
SourceDescriptionGenerators?
You wouldn't have each transformer to make its own WebDAV request.

What do you think?

Guido

Re: OT: spam

[Andreas Hochsteger <e9...@student.tuwien.ac.at>]

I didn't notice that there are virus mails coming through the mailing 
list before reading your mail.

I just saw that there are many Apache-Mails in my Virusalert folder, 
where all alerts from my university's mail server (which uses AMAVIS 
BTW) are automatically sorted in.
Such tools are really valuable these days!

And I wondered how the Cocoon mailinglist could resist them so long ;-)

Bertrand Delacretaz wrote:

> Le Mercredi, 27 aoû 2003, à 10:40 Europe/Zurich, Stephan Michels a écrit :
> 
>> BTW, it's annoying getting every day 400 sorbig mails.
> 
> 
> spamassassin rules here - I'm getting about 20 of these an hour, and 
> each one of them is cleanly spamassassinated by my mail server ;-)
> 
> -Bertrand
> 
> 

OT: spam (was: SourcepropWritingTransformer)

[Bertrand Delacretaz <bd...@codeconsult.ch>]

Le Mercredi, 27 aoû 2003, à 10:40 Europe/Zurich, Stephan Michels a 
écrit :

> BTW, it's annoying getting every day 400 sorbig mails.

spamassassin rules here - I'm getting about 20 of these an hour, and 
each one of them is cleanly spamassassinated by my mail server ;-)

-Bertrand

Re: SourcepropWritingTransformer

[Stephan Michels <st...@apache.org>]

On Tue, 26 Aug 2003, Gianugo Rabellino wrote:

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

No doubts. All I wanted was to write an ultimative DirectoryGenerator
which the SourceDescriptionGenerator.

My first approach was to combine the information of the directory
struture, properties of the source(SourceProperty), and properties
which would retrieve independently(SourceInspector). With the last
one I want to make the serveral derivations of the the DirectoryGenerator
redundant, like MP3DirectoryGenerator, ImageDirectory...

But I must admit that I neglected the KISS pinciple. Separating these
things into serveral transformer is a better approach.

But is there a way to nest the components like

DircetoryGenerator -> Information of Sources
SourcepropsWritingTransformer -> Getting additional properties

without a glue stylesheet like

DircetoryGenerator -> Information of Sources
XSLTTransformer -> transform every source to a 'getproperty'
SourcepropsWritingTransformer -> Getting additional properties

This would make my way easier

DircetoryGenerator
SourcepropsWritingTransformer
SourcePermissionsTransformer
SourceLocksTransformer
SourceInspectorTransformer

-> all information, which one can need

My 2 cents, Stephan.


BTW, it's annoying getting every day 400 sorbig mails.

Re: SourcepropWritingTransformer

[Gianugo Rabellino <gi...@apache.org>]

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

Re: SourcepropWritingTransformer

[Guido Casper <gc...@s-und-n.de>]

Gianugo Rabellino wrote:
> I'm about to tackle WebDAV properties handling, and I was happy to
> find that Guido has already provided something. :-)
>
> I am however a bit uncomfortable with the current implementation and
I
> wanted to see if it's just me not having the correct approach.

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

>
> A source property (both in webdav sense and in the  SourceProperty
> implementation) is made of three part: a local name (String), a
> namespace (String) and a value (DOM Element). It's worth noticing
that
> the property value is actually the *holder element* plus it's value
> (that is a text node - in case of a string value - or other
Elements),
> so that effectively you get, in case of webdav,
>
> <getcontenttype xmlns="DAV:">text/xml</getcontenttype>
>
> a property name of "getcontenttype, a namespace of "DAV:" and a
value
> of (xml-ized)
> <getcontenttype xmlns="DAV:">text/xml</getcontenttype>. User space
> tools will then give you a value of "text/xml", but this is a
> different issue.
>
> All this said, I fail to understand why this transformer is somehow
> reinveinting XML by using this syntax:
>
> <source:prop name="author" namespace="meta">me</source:prop>

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. On a second thought an alternative would be to have only
one <source:prop> element and have all immediate children be the
properties.

A value of a property however doesn't necessarily has to be XML.
Especially if you think of other Sources besides WebDAVSource.

>
> which forces, besides, to use a very risky solution to rebuild the
> property:
>
>    String pre = "<"+name+" xmlns="+quote+namespace+quote+">";
>    String post = "</"+name+">";
>    String xml = pre+value+post;
>    StringReader reader = new StringReader(xml);
>    Document doc = parser.parseDocument(new InputSource(reader));
>    SourceProperty property = new
>    SourceProperty(doc.getDocumentElement());
> ((InspectableSource)source).setSourceProperty(property);
>
> One of my biggest no-no is not to use string manipulation to build
> XML: this algo would fail in case the element has any XML reserver
> characters

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.

> or is an XML property value with nested elements.
>
> What about using good 'ole XML instead? I'm considering something
> like:
>
>    <source:props>
>       <myns:author xmlns:myns="meta">me</myns:author>
>    </source:props>
>
> This would allow using standard Transformer tools (startRecording()
> instead than startTextRecording()) to set the properties later. It
> would
> be much safer and a good bit more XMLish (and WebDAVish too). Also,
> this modification could be inserted directly into the
> SourceWritingTransformer without requiring a new transformer just to
> set properties.

It feels a bit like mixing concerns to me (setting properties and
writing content).
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.

Guido

Re: SourcepropWritingTransformer

[Stephan Michels <st...@apache.org>]

On Tue, 26 Aug 2003, Gianugo Rabellino wrote:

> A source property (both in webdav sense and in the  SourceProperty
> implementation) is made of three part: a local name (String), a
> namespace (String) and a value (DOM Element). It's worth noticing that
> the property value is actually the *holder element* plus it's value
> (that is a text node - in case of a string value - or other Elements),
> so that effectively you get, in case of webdav,
>
> <getcontenttype xmlns="DAV:">text/xml</getcontenttype>
>
> All this said, I fail to understand why this transformer is somehow
> reinveinting XML by using this syntax:
>
> <source:prop name="author" namespace="meta">me</source:prop>

+1

> which forces, besides, to use a very risky solution to rebuild the property:
>
>    String pre = "<"+name+" xmlns="+quote+namespace+quote+">";
>    String post = "</"+name+">";
>    String xml = pre+value+post;
>    StringReader reader = new StringReader(xml);
>    Document doc = parser.parseDocument(new InputSource(reader));
>    SourceProperty property = new SourceProperty(doc.getDocumentElement());
>    ((InspectableSource)source).setSourceProperty(property);
>
> One of my biggest no-no is not to use string manipulation to build XML:
> this algo would fail in case the element has any XML reserver characters
> or is an XML property value with nested elements.

I must use the string manipulation in the Slide block, because the
properties were stored in Slide in a very unusual manner. It was
a PITA. But the WebDAV implementation should handle this easier, I think.

Stephan.