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]
