I agree that I have been less than happy with the DOM backed structure,
it has made for a less than friendly client interface to
create/manipulate XMP data. My original thought was to model it similar
to the way PDFBox backs to source objects but in this case it is not as
practical and complicates things. Once you are at a good point and get
stuff in the repository I can help writing some of specific schemas.
I would also like to work on getting PDFBox incubated, it is my
understanding that the first step is to be nominated by a champion(I
assume that's you :) ), then with any luck we will find a sponsor. I am
still reviewing the incubation docs to get a full understanding of the
process.
Ben
Jeremias Maerki wrote:
After too much distraction last week I finally managed to dive in. I've
looked at Ben's code. His code operates directly on a W3C DOM. I've had
my negative experiences with the W3C DOM but the same applies to SAX.
Anyway, while playing with JempBox I've had quite a few "NAMESPACE_ERR:
An attempt is made to create or change an object in a way which is
incorrect with regard to namespaces" errors. This has to do with all the
namespace declarations.
I then decided to find out which way I'd go if I started from scratch. I
started by modelling the XMP data model in Java objects (without a DOM)
and wrote a SAX-based parser. The data model was then taught to render
itself to SAX events. The next step is to write schema support like Ben
has already done. I think my approach makes it easier to build a data
model that allows merging of two metadata trees. This is important in
the case of FOP. For example, I don't hold "rdf:Description" elements in
the data model. Metadata is simply a single bag of properties. The
properties are grouped into Description elements as recommended by the
XMP spec during serialization.
To get a more structured approach to this I've set up a Wiki page [1]
for the topic. The most important thing there are the requirements that
should give us directions. If I forgot anything please add it. I'll play
around with my package for a little bit and will then publish it for
review before we go any further (like committing to the repository).
[1] http://wiki.apache.org/xmlgraphics/ExtensibleMetadataPlatform
On 22.05.2006 22:59:03 Jeremias Maerki wrote:
On 22.05.2006 21:27:04 Ben Litchfield wrote:
Sorry for the delay in response, been quite busy lately.
I know the feeling. :-)
I am so interested that I actually started a project just last month,
it is currently hosted on SF at http://www.sf.net/projects/jempbox
LOL. Good thing I thought about you before taking off.
AFAIK, there are no open source Java XMP libraries, and I think there
is only 1 commercial one for that matter so I started it.
Actually, iText has some code, I think.
I would gladly give any/all JempBox code to XML Graphics Commons, or
collaborate on a new design.
That's very generous. I'm most interested in working together with you
on this. I'll take a look at your sources ASAP and will think about how
best to continue here. There are more than 2 possibilities:
- I work with you in your SourceForge project and we use the package in
XML Graphics. The license is ok for us but I guess we're probably in
favor of having the code in the vicinity. At least, I am.
- You donate to the sources to the XML Graphics project (IP clearing
process should be simple is this case [1]).
- We start again from scratch in XML Graphics Commons. I don't prefer
that in case your code is already a good start (which I assume).
- A full incubation as a new subproject would allow you to get direct
committership but an XMP component alone would probably not have enough
critical mass by itself. A full incubation of PDFBox with associated
components (including XMP) might be another idea. However, here's where
I'd stretch myself too thin at the moment. I'd need additional help from
within the ASF. But we could simply drop the hint in the Incubator.
Maybe we'll be surprised how many fish bite.
The problem from your POV when simply donating the sources is that
following the Apache way you'd have to earn your committer status first.
With the recent AFP renderer donation, the two original developers
didn't get committer status right away. That may seem a little unfair
however they were happy that way. They are more than welcome to join the
development and I'm sure they get priority consideration for committer
status if they become active. So, given what you've achieved with PDFBox,
committer status is probably something the can happen fairly quickly in
your case because you obviously know how open source works. I guess I
should ask on the Incubator list how they see a case like this. I'm open
to any solution. But it doesn't depend on me alone. All XML Graphics
people should be happy with the way we're dealing with this.
[1] Dealing with the ASF unfortunately means that you have to deal with
a number of bureaucratic hurdles all of which are designed to hold the
quality of Apache products high. It's much more easy to start a project
on SourceForge. That's important to know.
Ben
(cc'd Ben Litchfield, project admin of PDFBox, because he might be
interested, too)
I'm about to start a little XMP framework (parser, DOM, merger,
writer)
which I need to finalize PDF/A (and later PDF/X) support for FOP. XMP
is
a subset of RDF defined by Adobe to provide a metadata storage format
that is universally usable in many formats, PDF only being one of
them.
It can also be used with SVG and XSL-FO, although for the latter there
are no recommendations on the placement of XMP metadata. This is
something I will want to address when I gathered some experience with
this topic.
Since this XMP framework will be rather small and since it's not
FOP-specific I wanted to ask if anyone is against my implementing it
as
part of XML Graphics Commons (org.apache.xmlgraphics.xmp)? I don't
plan
to use any RDF libraries as the XMP's RDF subset should be easily
manageable with minimal code, i.e. no external dependencies other than
JAXP's APIs.
The main reason why I need this is that it should be possible to
specify
XMP inside an XSL-FO document. FOP should then use this info to
populate
the PDF Info object as well as the PDF Metadata object for the
document.
The metadata needs to be enriched with additional values which is why
I
need a parser and a easy-to-use in-memory representation.
The thing could also be interesting for Batik, in case anyone wishes
to
port metadata from SVG over to the generated output files (PDF, EPS,
PNG,
TIFF etc.).
Links:
- http://www.adobe.com/products/xmp/index.html
- http://partners.adobe.com/public/developer/xmp/sdk/index.html
Feedback and help welcome.
Jeremias Maerki
Jeremias Maerki
---------------------------------------------------------------------
Apache XML Graphics Project URL: http://xmlgraphics.apache.org/
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
