How is the JDF Product/Component structure for the gang jobs?

 
1
0
-1

JDF defines the SheetOptimizing process which creates the gang (merge) jobs.

I did not find a final reference however about the structure of the final gang jobs (were on the old CIP4 site). Is there still some description/drawing available?

This is an older related presentation I found back Component-IntentStruct_0301.ppt

Assuming the gang job can contain some Product Parts (like Covers) from different jobs and maybe one simple final job (like a flyer) how to describe?

In older mails I found some notes (but not final decisions):

  • should the root have Product as type (since not really a product)? suggestion was: not
  • should the root have a FinalProduct Component (since not really final)? suggestion was: not
  • should the Part/Product nodes have FinalProduct or PartialProduct? suggestion was FinalProduct (even if a part of the original job like Cover) to clearly indicate that it is a separate job/product and not parts to be bound together.
  • the Part/Product node contain the JobID and CustomerInfo of the original job
    CommentAdd your comment...

    1 answer

    1.  
      1
      0
      -1

      One of the reasons to define XJDF was the ability to allow multiple root products.

      Best solution: Quite simply use XJDF, which was designed with ganging in mind.

      If you really have to use JDF in a ganging environment:

      • should the root have Product as type (since not really a product)? suggestion was: not
        Yes - disregarding any philosophical questions of product exisitence: Finding a product in a ProcessGroup would most certainly break existing implementations.


      • should the root have a FinalProduct Component (since not really final)? suggestion was: not
        Probably not - there is no root product and the gang sheet is an intermediate "thing"


      • should the Part/Product nodes have FinalProduct or PartialProduct? suggestion was FinalProduct (even if a part of the original job like Cover) to clearly indicate that it is a separate job/product and not parts to be bound together.
        Why do you need products anyhow? If you need them, you need the complete product in order to understand the context of the product part. Thus each Root Product should be complete. Broken in XJDF: No linkage of product to sheet.


      • the Part/Product node contain the JobID and CustomerInfo of the original job
        That's what NodeInfo/GangSource was designed for. Thus - JobID is not required in the products.
      1. Koen Van de Poel

        1. I understand, but I had an unclear remark that influenced your answer for "should the Part/Product nodes have FinalProduct or PartialProduct"?

        → should the ComponentType  of the Output Component of Part/Product nodes include "FinalProduct" or "PartialProduct" ?

        2. GangSource

        So in JDF1.6 GangSource@AssemblyID then links BinderySignature with its original JobID. Fine. 

        How about linking to CustomerInfo? Customer Info may seem no important for a gang job but may be needed by prepress to create a slug line with the customer name beneath each BinderySignature in the gang job (but the gang creator could maybe add a string explicitly using StripMark.)

      CommentAdd your comment...