cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylvain.wal...@anyware-tech.com>
Subject Re: FileWritingTransformer
Date Mon, 18 Feb 2002 21:01:17 GMT
Stefano Mazzocchi wrote:

>Jeremy Quinn wrote:
>
>>>Question 1#: how hard would it be do to
>>>
>>><xfwt:write src="xmldb://localhost/result.xml">
>>> <page>
>>>  ...
>>> </page>
>>></xfwt>
>>>
>>Currently there is a load of code in FileWritingTransformer that is File
>>specific, I check for a 'file:' prefix on resolved sources.
>>
>>I think we would want Sylvain's WriteableSource would'nt we?
>>
>
>Yes, I definately think we should go down this road.
>
>>As I understand it we would need stuff like:
>>
>>        WriteableXMLDBSourceImpl, WriteableFileSourceImpl etc.
>>
>>Or use/extend Vadim's XMLDBTransformer?
>>
>
>I'm afraid of having a bunch of different transformers that react on
>different namespaces just because the storage location is different.
>
>I think that a writable resource would make perfect sense.
>
Cool ! I've had this on my todo list for a while now, and I think it's 
time to do it now :)

I'll start with a WriteableURLSource, so that we can play with it before 
going further on more complicated implementations.

But as I'm on ski holidays this week, my work will be related to weather 
conditions ;)

>>>Question #2: do you check if the <xfwt:write> element includes *one* and
>>>only *one* nested element? If not, we could end up with problems later
>>>on.
>>>
>>No I don't, I'll add that to my list, thanks.
>>
>
>'welcome.
>
>>Two other issues ....
>>
>>I need to make sure the Transformer does not emit more than one 'copy' of
>>each namespace prefix, currently multiple sources (FileGenerator &
>>XInclude) with multiple copies of the same namespace, cause multiple
>>identical xmlns attributes in the Serialized file, causing subsequent
>>Parser errors when it is read.
>>
>>A namespace declaration for xfwt is always output to the files it writes to.
>>It was already in the Document that the file is generated from so it
>>happens automatically.
>>
>>I am trying to decide if this is a good thing or not.
>>
>>In one way it is quite cute ;) a kind of signature, but in another sense it
>>is pollution, if there are no xfwt tags in the file, why the hell should it
>>declare that namespace?
>>
>>If I filter it out however, then no-one can edit files containing that
>>namespace anymore.
>>
>
>Congratulations: you win the price of 'first man on cocoon-dev to crush
>into the wall of meta-namespacing' :)
>
>Really: this is a *very* big issue and it is somewhat similar to way
>XSLT is capable of performing namespace virtualization in order to allow
>stylesheets to work on stylesheets.
>
>But this is a *very* complex thing and always smelled like FS to me.
>
>I would personally filter out all the content of the 'xfwt' namespace
>before saving and in case people has to write content that includes a
>'turned-off' 'xfwt' content (say, an XML document that explains the
>'xfwt' markup), that could be written in CDATA sections.
> 
>
>>Which is the right way to go do you think?
>>
>
>I would filter them out before saving and forget about it.
>
Namespace issues that appear when extracting parts of a SAX stream are a 
real PITA. I personnaly use two utilities to make life easier :

The first one is org.xml.sax.helpers.NamespaceSupport. It helps tracking 
namespaces declarations so you can know all active namespaces that 
should be declared a the beginning of a document extracted from a SAX 
stream.

The second one is an XMLPipe of mine called "NamespaceNormalizer" : it 
moves the declaration of all namespaces *used* (not only declared) in a 
document at the top of this document. This is really useful to reduce 
the size and increase readability of some xsl-produced documents. It's 
not in the CVS now, but I can add it if people think it is usefull.

Sylvain



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message