Hello Jaroslaw,

> > I don't think, we should ban our data into ODF container fields, ODF
> > metadata and so on. That would mean there will be no benefit of XML
> > anymore to us. In that case nothing could check validity, nothing can
> > understand it without being an ODF parser.
>
> Kay,
> That's true. Now the question would be that, since mail-merge-like
> reporting features have to be developed in (preferably) in one way not two,
> should we forget about utilizing text:user-field-get for the features, in
> favour of (obviously more powerfull and covering more cases XML
> transformations); -- and then just have support for user fields just
> because ODF spec contains this and oo.org supports this explicitely in its
> GUI.


At the very basis, what I want is not to mail merge, but to be able to edit 
XML documents. Speaking of mail merge is to jump to the application of the 
feature.

Obviously one important use case would be to create ODF documents with the 
original data mixed in, or mail-merged if you want, but it's also about the 
user being able to add things that were not there, but allowed by the schema.

Your external data should be able to live as XML document(s) (but that should 
not be a requirement to mail merge too). If something is then formatted to be 
inside ODF metadata or a ODF header with the original tags intact, it is just 
the difference of allowing to keep tags intact or not, and if you want any 
checks applied or not. 

To us it would be bad if a copy&paste operation could lead to a document that 
misses a mandatory field or a field with unallowed content. The whole point 
is about being able to enforce content properties.

Do I think mail merge needs to change? Probably not, esp. as (having to have?) 
a schema may be something many applications won't like and see as overhead.

Best regards,
Kay Hayen
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel