xmlgraphics-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Litchfield <...@benlitchfield.com>
Subject Re: A small XMP framework
Date Tue, 06 Jun 2006 14:59:23 GMT
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: general-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: general-help@xmlgraphics.apache.org
>
>   


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message