start working on odf4j

Hello,Bernd Eilers:

I successfully installed Netbeans IDE, and checked out the
project in
cvs, thanks for your kind help
and I am going through the code, and doing some test by
using
OdfPackageTest.java and OdtToTest.java,
OdtToTest2.java, to try out something, I think i understand
the project
pretty much now.

are the org.openoffice.odf package, org.openoffice.manifest
and
org.openoffice.schema finished already?

Regards
zhao sheng


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeodftoolkit.openoffice.org
For additional commands, e-mail: dev-helpodftoolkit.openoffice.org

zhaosheng wrote:
> Hello,Bernd Eilers:
> 

Hi Zhao Sheng,

> I successfully installed Netbeans IDE, and checked out
the project in
> cvs, thanks for your kind help
> and I am going through the code, and doing some test by
using
> OdfPackageTest.java and OdtToTest.java,
> OdtToTest2.java, to try out something, I think i
understand the project
> pretty much now.
> 

Nice to hear.

> are the org.openoffice.odf package,
org.openoffice.manifest and
> org.openoffice.schema finished already?
> 

Well the org.openoffice.odf.manifest packge pretty much
supports every
elements that there are defined for Manifest files in the
current
specification, I am not expecting changes there soon.

For the org.openoffice.odf package support for crypted
documents is
lacking in the OdfPackage class [ we currently consider this
a not so
much important item with a huge effort needed ] and I have
some
unfinished idea in mind on how to add support for embedded
objects  (eg.
when you have a chart inside a calc document or a calc
document inside a
writer document) by adding an additional abstract base class
to
OdfPackage and/or creating an additional OdfObject class or
something
like that. Note that in OpenDocument files you basically do
have simply
subdirectories containing the XML Streams for such embedded
objects
inside the Package/Zip file, the idea is to have an
OdfObject class know
it´s parent OdfPackage and in most of it´s methods than
delegate to
similar methods in the OdfPackage class. This would likely
also require
changes to the OpenDocument and OpenDocumentFactory classes.
Haven´t
thought that through yet tough.

And with the schema files the thing is that they are
currently just not
used by the parsers reading the manifest file or creating
DOM trees
inside the OdfPackage class. We currently just use
non-validating
parsers there and might eventuall want to add support for
optionally
using validating parsers which may use the schema files
than. But I
would also consider this a not so much important item
compared to
defining API´s for TextDocuments, Spreadsheets and
Presentation documents.

For the OpenDocument class I think this should get common
methods which
can be used on all types of OpenDocument files like asking
for and
setting document propertys eg. Author, CreationDate, ... in
the future.

And than well as long as work is of course going on in the
Oasis
OpenDocument specification groups and they are about to
create new
versions of the specifications everything is of course
subject to change
and nothing is ever finished.

Oh bye the way: for the org.openoffice.odf.tools package it
would be
nice if we could create an example there which would be
using the
transform method of the OdfXMLHelper class in package
org.openoffice.odf.xml to apply an XSL-Transformation to an
OpenDocument
file. I just started to fantasize about an ODF->UOF
Converter
implemented as XSL-Transformation which would of course be a
cool thing
to have. But that´s probably way too complicated so we
might need to
search for something smaller which can be used as an example
here.


So you see what´s there is really only a start and there is
much which
can be done.


> Regards
> zhao sheng
> 

Regards,
Bernd Eilers

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeodftoolkit.openoffice.org
For additional commands, e-mail: dev-helpodftoolkit.openoffice.org

Hi:
Bernd Eilers wrote:
> For the OpenDocument class I think this should get
common methods which
> can be used on all types of OpenDocument files like
asking for and
> setting document propertys eg. Author, CreationDate,
... in the future.
the OdfPackage class actually provide all the function to
handle the 
OpenDocument file,including load
save, interpret the general information for the file( but
not the 
actually content, right?).
I see the DOM is used, what is the thought there? because it
is fast for 
not large file?

For the OpenDocument class, now I think it is lack of common
methods for 
all the types of OpenDocuments
and do you think it is worth to start now to add them?

> Oh bye the way: for the org.openoffice.odf.tools
package it would be
> nice if we could create an example there which would be
using the
> transform method of the OdfXMLHelper class in package
> org.openoffice.odf.xml to apply an XSL-Transformation
to an OpenDocument
> file. I just started to fantasize about an ODF->UOF
Converter
> implemented as XSL-Transformation which would of course
be a cool thing
> to have. But that´s probably way too complicated so we
might need to
> search for something smaller which can be used as an
example here.
So Maybe I can also start doing the XSL-Transformation to an

OpenDocument file,
what do you think? is it feasible? say start from easy
examples.


Best Regards
zhao shen




 

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeodftoolkit.openoffice.org
For additional commands, e-mail: dev-helpodftoolkit.openoffice.org

zhaosheng wrote:
> Hi:
> Bernd Eilers wrote:
> 

Hi Zhao Sheng!

>> For the OpenDocument class I think this should get
common methods which
>> can be used on all types of OpenDocument files like
asking for and
>> setting document propertys eg. Author,
CreationDate, ... in the future.
> 
> the OdfPackage class actually provide all the function
to handle the 
> OpenDocument file,including load
> save, interpret the general information for the file(
but not the 
> actually content, right?).

Yes! It basically provides the support to handle the ODF
Package file 
format including support for adding content, getting access
to DOM 
representations of included XML Streams, loading and saving
and handling 
the included Manifest file.

> I see the DOM is used, what is the thought there?
because it is fast for 
> not large file?

DOM is just a standard method to have an in-memmory
representation of 
XML content and to manipulate that. ODF files are basically
zip files 
containing multiple XML streams together with binary
content, eg. for 
images. The tought there is that derived classes like
OpenDocument, 
TextDocument, SpreadsheetDocument, PresentationDocument
would provide 
methods to modify the document or get information about the
document 
which would operate on those in-memmory DOM trees for the
content.xml 
and styles.xml subcontents. The base class OdfPackage than
just keeps a 
pointer to those modified DOM trees to be able to save the
modified 
document.

> 
> For the OpenDocument class, now I think it is lack of
common methods for 
> all the types of OpenDocuments
> and do you think it is worth to start now to add them?

Yes sure!

> 
>> Oh bye the way: for the org.openoffice.odf.tools
package it would be
>> nice if we could create an example there which
would be using the
>> transform method of the OdfXMLHelper class in
package
>> org.openoffice.odf.xml to apply an
XSL-Transformation to an OpenDocument
>> file. I just started to fantasize about an
ODF->UOF Converter
>> implemented as XSL-Transformation which would of
course be a cool thing
>> to have. But that´s probably way too complicated
so we might need to
>> search for something smaller which can be used as
an example here.
> 
> So Maybe I can also start doing the XSL-Transformation
to an 
> OpenDocument file,
> what do you think? is it feasible? say start from easy
examples.
> 

You mean kind of adding helper classes or methods to support
custom XML 
to ODF conversion by using XSLT and providing examples for
using them?

Well if we could do this this would be of course a good
addition.

But I currently have no idea on how to handle the thing that
an ODF file 
consists of multiple XML Streams ( eg. content.xml and
styles.xml ) 
which are packaged together into a zip file. Being able to
have multiple 
XML output trees is only available since XSLT 2.0 and I
don´t know if 
available java API´s for XSLT do provide support to plug in
something 
like a custom URI Handler for Results which would allow us
to define 
something like an odfpackage:// URI or similar which could
be used 
inside XSL-Transformations to store the results of a
XSL-Transformation 
into the different XML Streams of the ODF Document. This
must be evaluated.

The other thing is that there is something like an ODF flat
XML file 
format defined where the whole ODF Document is not packaged
into a zip 
file but saved as one real XML file and where the binary
content like 
images is than stored there base64 encoded. If we would have
support for 
converting such flat ODF XML file format files to and from
an ODF 
Package file format other types of XML->ODF conversions
would be 
possible using just one XML Result Tree in the
XSL-Transformation which 
would than be of such ODF flat XML file format.


What is already possible with the current framework tough is
to create 
an empty ODF document or to use a template and than have two

XSL-Transformations for your input XML document one for
creating the 
content.xml subcontent and one for the creating the
styles.xml 
subcontent. If you would want to create an XML->ODF
conversion example 
which works this way this could be using the
getContentStream() and 
getStyleStream() methods on the OdfPackage class, call
getOutputStream() 
on the result returned and use that as a 
javax.xml.transform.stream.StreamResult for the two
XSL-Transformations.

Depending on the concrete XML input file format it might
also be 
possible to use just one XSLT conversion for creating the
content.xml 
subcontent and use predefined styles which are loaded from a
template 
document. I could imaging doing something like this for
converting a 
company defined sales order XML based file format to an ODF
Document 
which would be the bill for the product ordered. Maybe you
can find some 
better ideas for easy examples. Using some XML based file
format which 
is already defined as some kind of standard in some area for
examples 
would be of course better than using made-up example file
formats.

> 
> Best Regards
> zhao shen
> 
> 
> 
> 

Kind regards,
Bernd Eilers

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeodftoolkit.openoffice.org
For additional commands, e-mail: dev-helpodftoolkit.openoffice.org

Bernd Eilers wrote:
> zhaosheng wrote:
> 
>> Hi:
>> Bernd Eilers wrote:
>>
> 
> Hi Zhao Sheng!
> 
>>>[... snip ...]
>>
>> So Maybe I can also start doing the
XSL-Transformation to an 
>> OpenDocument file,
>> what do you think? is it feasible? say start from
easy examples.
>>
> 
> You mean kind of adding helper classes or methods to
support custom XML 
> to ODF conversion by using XSLT and providing examples
for using them?
> 
> Well if we could do this this would be of course a good
addition.
> 

Just one more comment:

Providing examples for converting from ODF to some XML based
file format 
or other possible output formats XSLT provides is of course
much easier 
as support for accessing all XML input streams of the ODF
document 
inside one XSL-Tranformation by starting with one subcontent
stream (eg. 
the content.xml subcontent) and using relative urls for
getting the 
other ones by using the XSLT document() function inside the

XSL-Transformation is already there. Simple examples might
not even need 
that and just do an XSL-Tranformation on the content.xml
only to get 
their result document. Simple examples might eg. convert
documents 
created from special use templates to special use XML
documents.

Kind regards,
Bernd Eilers


------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeodftoolkit.openoffice.org
For additional commands, e-mail: dev-helpodftoolkit.openoffice.org