[Printing-architecture] Optimizing MicroJobTicket - JTAPI 'native' symbols - second n ote

[Petrie, Glen]

Ira,

Is coherence, at the level we are discussing needed or wanted?  Or is what
is needed/wanted is a translation mechanism to "seamlessly move between
job-ticket representation"?

Coherence to me and in this context would mean consuming any job-ticket
format and outputting a common (read as coherent) job-ticket representation.


          JDF -----\
                   \
          MJT ----->---->>> common job-ticket representation 
                   /
          XYZ JT --/

A translation mechanism says "take what I got and give me something I can
use".

          JDF <<<<<<<<
                      ^  MJT becames a JDF
          MJT >>>>>>>>^
                   
          XYZ JT --/


I believe in coherence but I also believe the world only needs/wants
translation.

Therefore, the project as I proposed uses JTAPI to create the translation
service; as I believe was the originally intended.  When you add the concept
of a binary (internal) job-ticket representation writer/reader you can
achieve a small degree of coherence or at least start a path to coherence.

I also designed the project to accept only a few variations of a MJT.  This
is so Lars would not have to process all the possible attribute values of a
MJT (read this as IPP).  He only needs to concentrate on the one in the
pre-defined MJTs and focus his development time on the core JTAPI code.  I
had to scope the project as a summer project but tried to figure out how to
structure the activity so that is could continue afterwards. 

Therefore, let's leave MJT as is.   I actually picked MJT because I
understood it to be simplified job-ticket based on IPP and PWG content.   

gwp 

p.s. 

Isn't defining the second standard suggested below creating another
job-ticket format?  If we are going to do that then I would rather spend the
time create the specification for the binary (internal) job-ticket
representation discussed above.  

gwp 

> -----Original Message-----
> From: Ira McDonald [mailto:blueroofmusic at gmail.com]
> Sent: Tuesday, April 01, 2008 10:00 AM
> To: printing-architecture at lists.linux-foundation.org; Lars Uebernickel;
> Petrie, Glen; Ira McDonald
> Subject: Optimizing MicroJobTicket - JTAPI 'native' symbols
> 
> Hi,
> 
> Right after I suggested we just use MJT for any needed interprocess
> serialization of a parsed job ticket in the JTAPI Library, I thought
> 
> "Hey, the current MJT uses IPP standard property names and values
> and a PWG namespace - duh!"
> 
> I suggest that I revise the PWG MJT working draft to be an OP MJT
> working draft (which I need to do anyway).
> 
> I should define a second standard JTAPI namespace for MJT, that uses
> JTAPI standard property names and values - this would let the external
> job ticket match exactly the OP canonical names from JTAPI - a very
> long-standing coherence goal that Glen has championed and I support.
> 
> However, for use with CUPS and/or PAPI integration, support for the PWG
> IPP names in MJT is also important.  Hmm...
> 
> Comments, Glen and Lars?
> 
> Cheers,
> - Ira
> 
> --
> Ira McDonald (Musician / Software Architect)
> Chair - Linux Foundation Open Printing WG
> Blue Roof Music/High North Inc
> email: blueroofmusic at gmail.com
> winter:
>  579 Park Place Saline, MI 48176
>  734-944-0094
> summer:
>  PO Box 221 Grand Marais, MI 49839
>  906-494-2434