xmlgraphics-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremias Maerki <...@jeremias-maerki.ch>
Subject Re: A small XMP framework
Date Tue, 06 Jun 2006 08:24:39 GMT
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: general-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: general-help@xmlgraphics.apache.org

View raw message