Combined notes - TSC week of June 16, 2003 - Linux Foundation



Combined notes from the TSC meeting, June 16-20, 2003, Washington DC

Monday, June 16, 2003

General notes;

1. We will read through the spec page by page and wait to see if anyone has comments or questions.

2. If we reject elements of a proposal, it will be sent back to the working group to either rewrite or remove those elements before sending the proposal onto the spec writing group.

3. Asset Transfer is sent back to group to finish DigitalNetwork versus DigitalMedia

4. FileSpec may be added to 1.2 spec and changes dealing with archives will be folded in.

5. TiffFormatConversion may be added to 1.2 spec and changes dealing with JPEG2000 and SourceCS coordination will be folded in.

6. Finishing proposal is sent back to finishing group to deal with rejected items and finishing of PrintRoll definition.

7. Proof of concepts:

a. All JDFs created for proof of concepts must be comprehensive real-world examples that illustrate the workflow and the use of the proposal within that context.

b. Asset Transfer must provide comprehensive real-world JDF’s that illustrate the lifecycle of ArtDeliveryIntent through the DigitalDelivery. These JDF’s must succeed in being checked by CheckJDF.

c. FileSpec will be sufficient by delivering the schema changes and examples showing how to use archive files.

d. TiffFormatConversion must provide JDF examples that illustrate using all of the sub-elements and Tiff tags.

e. Finishing:

i. StatusDetails/ModuleType are ok via the proposal alone

ii. Component Condition need JDF examples submitted showing how components describe both good and waste output, and how destructive QA is applied.

iii. Feeding needs to provide JDF examples of the lifecycle of a process using feeding along with complex real-world examples of the same.

iv. PrintRolling needs a comprehensive example JDF using the process.

v. Bundling needs a comprehensive example JDF using the process.

Asset Transfer:

1. How is WWW ChannelType used (Tom Hastings)? It is the same as web, but existed already in 1.1a.

2. Instead of example values for the NMTOKEN lists, we should use pre-defined values.

3. WWW ChannelTypeDetails are now Form or Target

4. User ID/password currently can be provided in plain text in the ftp URL. A proposal will be ready by year’s end for security.

5. Should we add an overwrite/append for file URLs. No – the writing system should always write the aggregated contents of the file.

6. Remove reference to unknown from ChannelUsage.

7. Add Warning to CustomerMessage::ShowList

8. Remove CustomerMessage::OperatorText, as it makes no sense to be there.

9. Consensus is that CustomerMessage is defined purely as a process message utility and does not take into account the submission of JDF intent. Sent back for fixing (it should allow for both and include workflow phase information such as start/end of prepress, production, finishing, ready to ship, etcetera).

10. Should CD delivery be part of the DigitalDelivery process? If so, we could restructure the DigitalDeliveryParams to have sub-elements for DigitalNetwork versus DigitalMedia (shipped via fedex for example). Sent back to working group for definition.

11. Do you need the DigitalDeliveryProtocol attribute?

12. Is duration sufficient for the Storage attribute? You might want to specify the event that signals when you are done storing. For now, we are moving the Storage attribute to a sub-element where it will be the StorageDuration.

FileSpec:

1. We should not put “Clarified in 1.2” in the specification.

2. We need to create a sub-element that specifies the application environment (plug-ins/extensions, fonts, etcetera). This should be done for 1.3.

3. Should Compression be an NMTOKEN? Yes.

4. Fix description of encoding order in the description of Compression.

5. “is expected to” is replaced by “must” in wordings.

6. What do you put in MIMEType when a file is a zip file? There are two cases – where you refer to a zip file as a file in and of itself, and when you are referring to a specific file within a zip file. The second case is not currently handled, and is being sent back to the working group to define how to do so. This second case is akin to a cid reference to a multi-part mime package. Also, is there a use case for batch processing from an archive? If so, we need to refer to multiple files within an archive.

7. Use the application/zip since it is a registered mime type.

8. Mike Scrutton will provide the URL for the MacBinary specification.

9. MimeType references to archives will not be reviewed until the working group determines how to refer to individual files within an archive.

10. We don’t think that service pack should be part of the OS version at this time.

11. There is no issue about templates being reusable, so a URL does not need to be present in a template – you just add it to the submitted JDF.

12. What’s the difference between UserDocumentName and UserFileName. There is none; we need to clarify the description of UserFileName to indicate it is the document title.

13. FileAlias::Disposition needs to be made optional if it has been deprecated. Also, FileSpec should be optional and the URL should be optional. We probably also need to add wording about FileSpec causing Disposition and URL (etc) to be ignored. Wordsmithing about FileSpec is needed.

14. Finish description in the tables at the end of the proposal.

TIFF format conversion:

1. Remove MimeType, as it is in the output run list.

2. Stripped not Striped in Segmentation

3. Change TileSize to XYPair type.

4. TiffEmbeddedFile::TiffEmbeddedFileSpec needs to be renamed FileSpec.

5. Need to add JPEG2000 to ImageCompressionParams (Mike Scrutton to look up). We want the parameters to comply with the definition of the JDF 1.5 specification.

6. Coordinate SourceCS with the final version as approved (if approved) by the TSC. (Martin Bailey)

Finishing:

1. Add Component::Condition to specify whether the component is Good, Waste, type of waste, etc.

2. If the feeding process is to be combined with DigitalPrinting, it will have to be able to be driven based on the RunList/BundleItemIndex.

3. Feeder positions are non-negative integers.

4. A digital printer with a folding feeder will need to model it as a process group; not a combined process. We need to indicate this is appropriate in the description of process groups in the spec.

5. The input to feeding and collating need to be coordinated.

6. FeederQuality ( FeederQualityParams

7. Note only one of Orientation or Transformation may be specified (we need to make sure this is also true throughout the spec).

8. Roller process would need to be modeled as taking its input through a pipe (also the feeder process).

9. Added a PrintRoll resource (Implementation resource) to the PrintRolling process.

10. Send details of PrintRoll back to the finishing group to finalize.

11. Only one of BundlingParams::Copies and Length may be specified.

12. TBD’s for new strip binding are rejected.

Z-fold:

1. We need to create a fold catalog of fold types used in finished products if we want to have a simple description; otherwise we should just let the fold process describe the fold itself. A simple description would enable easy UIs.

a. Resolved by adding a new designator to the fold catalog (P-*) intended for product fold definitions.

2. What about envelope production (1.3)

Tuesday, June 17, 2003

General notes:

1. We should search the frame document for “reference source not found” after integrating all changes to see if we’ve missed any unresolved links.

2. There is still confusion over the JDF lifecycle (such as who adds audits).

3. Make transformations and UnitType into new data types.

4. We need to properly define regExp datatype

5. Remember that the way we describe default values is being changed to provide them in the left column of the tables. We also are removing specific selection of system specified behavior.

Capabilities:

1. Craig & Rainer to contrast capabilities with schema

2. Remove AllFoundDynamic from ExecutionPolicy, making AllFound the same as AllFoundDynamic and clarifying the text (done).

3. We need an example of TypeExpression

4. Should we promote Context to DevCaps from DevCap

5. Add a reference to where units are defined in UnitType attributes (or put the unit types in the table). We might want to make a new datatype called UnitType

6. Review to make sure all units defined in the spec are allowed by UnitType

7. AllowedShift (Matrix State) define which values are min and max

8. We need to wordsmith the descriptive paragraph for the ValueLoc subelement.

9. Remove “legal” from capabilities (rename as “supported”)

10. Change LocValue and ShortLocValue to Value and ShortValue in the examples.

11. Should Action=DependentDisplay still be one of the supported values (Bob to determine).

12. Check whether we should use Action=Warn or Warning

13. The abstract Expression sub-element should be renamed Term to clarify its relationship with the root Expression sub-element. Wordsmith as necessary.

14. Add table of all Term instantiations as part of the subelement structure section (1.3.8.15).

15. For all Present* attributes, add wording about “without operator intervention”.

16. Replace “if not present” with “if not specified”

17. Verify that all evaluations and states are consistent.

18. Add wording to operator lists to indicate they are derived from Term and change Expression to Term in all of them. Also do this to the *Evaluation elements.

19. For operators, indicate that there are two or more Terms rather than listing it twice.

20. Fix capitalization of Macro::Choice, Set, and Call

21. Allow the editor to redraw the logical layout diagram for the Macro sub element to make it look like something that doesn’t come from XML Spy.

22. Fix capitalizations for Choice::When and Otherwise.

23. Wordsmith description for 1.3.9.9 to better describe its use.

24. The capabilities group should resolve the issues, then review with the preflight group before sending the the spec editors.

25. We are not going to move capabilities into a separate namespace.

26. Add a capabilities attribute to indicate that you treat unknown versions gracefully. This may be a wildcard in the Version attribute.

Versioning:

1. What if we simply add an enumeration to an attribute. How is this done? The answer is that you need to make the containing element a new version.

2. If 1) is true, then should a resource being consumed by multiple nodes be the least common denominator resource version, or should lower nodes ignore unknown attributes.

3. If we have a single namespace, the Version attribute does not give any useful data either to a device or an agent.

4. We will not change the semantics of existing attributes when creating new versions of JDF.

5. Devices that perform schema validation will either have to be able to get new copies of the schema, or ignore unknown JDF namespace attributes if they are not MustHonor. In this case Version could be used to determine whether to trap schema errors when validating. This would be optional based on the needs of the workflow the device exists in.

6. If an agent is updating a JDF and the version of a resource that it writes is greater than the root version of the JDF, then it must update the Version attribute of the root node.

7. Rainer to flesh out the section on versioning. The full TSC will review it.

Schema Development Contract:

1. Will automating the schema generation help us? In part is the answer. Some parts of the schema will still need to be hand generated, and the final schema still needs to be validated. In terms of time to do this, it might shorten future schema development time.

2. We could also hire contractors working under Graham’s supervision to either develop tools or to create the new schema entries. Mike to make a proposal.

Wednesday, June 18, 2003

General notes:

1. If it’s on, it will work…

2. The system behavior group has proposed to be a clearing house for all new NMTOKEN definitions that would go into the spec in the next version. Tom Hastings has volunteered to do this.

3. We need to make an editorial pass through the spec to comment on why items have been deprecated. Jim Harvey’s team could pass back to the TSC requests for information when they do not have descriptions.

4. We need to add information in a JDF to indicate whether the device should delete the source JDF at the completion of job.

5. Table 1-2 needs to be verified that all data types from appendix A are included.

6. Go and verify that the description of MustHonor indicates that when an attribute or attribute value is not understood that it must be treated as unsupported. And in the implementation guide, make sure we point out the importance of SettingsPolicy.

7. Quality control and verification need to be sync’ed up.

8. We should consider putting a suggested reading list into the implementation guide. Also explain that since we do not delete elements in new versions, we cannot change cardinality that further restricts the element and retain backwards compatibility.

9. We need to describe how to do soft proofing.

10. Make sure that all input resources to processes that have a proposed change in cardinality to optional have those changes rejected.

11. Make sure new span types are added to the tables and schema

12. ProofingIntent/ScreeningIntent – review with Albert on Thursday

13. MediaIntent – review with Ann on Thursday

14. AutomatedOverprintParams – review with Ann on Thursday

JMF:

3. Synchronization files are rejected and sent back to JMF for rethought. We don’t believe there is any reason for them.

4. ResponseURL is returned to JMF to determine whether a file pattern is required.

5. FileScheme and FileSchemeStartNo need to be aligned with FileSpec patterns.

6. The use of level X in section 5.3 is confusing and misleading. The JMF group needs to consider whether to remove that concept from the section.

7. We should spend time in the future restructuring the JMF chapter so that it presents messages in a fashion consistent with the rest of the specification (and make it easier to read). This should not gate 1.2.

8. The Queue queries QueueEntryID descriptions need to be corrected so that they refer to the contents of the queue rather than jobs executed by the device. The JMF group should review these for consistency. An Example is StatusQuParams::QueueEntryID.

9. Add “and ignore Part” to areas where it is stated “if QueueEntryID are available then … is ignored”.

10. ShutDown command is sent back to the JMF group to determine how best to deal with queue persistency versus non-persistency and how to deal with it (telling the agent whether its queue persists between shutdowns, whether to control flushing the queue on shutdown, etcetera).

11. What params should be in the WakeUpCmdParams (should you immediate start to execute jobs, wait for a start processng command, …). You should also be able to specify which module to wake up.

12. Condition is sent back to the JMF group to determine the contents of the enumeration. Not enough information is currently conveyed by that currently (Offline, emergency stop pressed, …?).

13. Add table row for QueueFilter additions to CommandTypeObj in the queue commands.

14. Members of the TSC do not believe that RepeatQueueEntry would work for the general case. The completed JDF node has been modified by the command, and no longer represents the complete processing that occurred. We don’t see how this would work with a JDF that has multiple nodes in it. We think this is an application issue rather than a messaging issue.

15. Need a message for a device to tell a controller that it is going to sleep (for instance, a device after a timeout with no work goes to sleep). This will be handled by a signal. Wordsmithing is needed to describe how this works.

16. How should ReturnURL interact with TargetRoute?

17. The section on HTTP MIME/Multipart/Related Submission should refer to the packaging section.

18. Add details about https

19. Fix the last sentence in 8.2.4 – MIME Types and File Extensions

20. Add information as to the content of http headers (Content-Type)

21. Proof of concept for the JMF group would require a prototype implementation of resubmit queue entry and associated workflow to make it work.

Digital Printing:

1. Fixed up the definition of deprecated to not imply you should never use a deprecated attribute.

2. The coordinate systems section (2.5.3.1) still is incomplete. Sent back to coordinate system WG.

3. Instead of adding ProofRunAndGo to the node’s activation, add a DirectProof Boolean to DigitalPrintingParams. Set back to working group.

4. Templates must always be rejected if submitted to a device.

5. TemplateVersion could have examples of versions, but the phrasing currently used “May be of the form…” is rejected.

6. Removed Version modifications in favor of TSC versioning work.

7. Add xsitype to the node structure. Sent to Graham for proposal.

8. CustomerJobDescription is rejected, as a comment can be used to provide details to supplement CustomerJob.

9. The description of NoOP has been modified, including that the default has been removed and replaced by “if false or not specified”.

10. Rejected changes to ResourceUpdate, as both were incorrect. Rainer will work with Tom to make sure that the descriptive text is understandable.

11. Rainer has a better description for the RunPage partitioning key, so we have rejected the changes.

12. Location names that have been removed from the locations within printers (3-26) are rejected. The working group may not remove these, as they were normative in the 1.1 specification.

13. We have wordsmithed the “Proofing and Verification” section. It is now “Approval and Verification”, and have clarified the additions to the section. It needs more wordsmithing for completion.

14. You cannot arbitrarily change the cardinality of input resources to processes from required to optional simply because all attributes of the resource are optional. Some JDF processes require the JDF default behavior to be instantiated when the attribute is not supplied. In that case, the resource must be provided as a placeholder to enable the schema to supply the defaults (or for the device’s parser to do so). The only time the resource is optional is when undefined behavior is acceptable. All instances of this sort of change need to be reviewed with this in mind. Rejected for ColorSpaceConversionParams.

15. ImageSetting may not be used to generate soft proofs.

16. Change the Media input of ImageSetting to optional is rejected.

17. Changing of the cardinality of Layout to optional in Imposition is rejected.

18. Changing of the cardinality of InterpretingParams to optional in Interpreting is rejected.

19. Changing of the cardinality of LayoutPreparationParams to optional in LayoutPreparation is rejected. Also for PDFToPSConversionParams, ScreeningParams, TrappingDetails, and many more. We want to also leave open the possibility that an attribute with a well-defined default might be added to a resource that previously had none in it.

20. We need to think about what to do if SeparationControlParams::TransferFunctionControl is not specified. The prepress and digital printing groups need to consider this.

21. ConventionalPrinting may not be used to generate proofs.

22. Wordsmith to indicate that Component proof inputs to Conventional printing may not have been generated as proofs in the original printing process. Rainer and Markus. The same needs to be done for DigitalPrinting.

23. DigitalPrinting may not be used to generate soft proofs.

24. The definition of LayoutIntent::Pages is still incorrect, as it should not generate different results based on the Z-fold issue listed in the proposal. Sent back to the working group for further work.

25. ReferenceEdge needs to be worked more. Sent to coordinate systems working group.

26. We will continue review on Thursday.

Rainer’s miscellaneous changes:

1. “0~” notation for unbounded in range lists is not sufficient. You must have some token describing +/- unbounded. This is bounced back to Rainer, Gareth, and Mike.

2. LabColorRange may not be approved as a new data type until review of the proposed color changes.

3. Activation=Informative needs discussion with regard to submitting JDF’s to a controller and their lifecycle.

4. Definition of how to expand process groups is sent back for further discussion until consensus is reached.

5. And time ran out…

Thursday, June 19, 2003

General notes:

15. The calling card was a waste of money…

16. Perhaps for the 1.3 spec we can get application vendors involved (soft proofing display, color management, etc) where we can agree upon a consistent method of color management in the workflow and add specific JDF controls to enable this.

17. The TSC will meet for 2 hours twice a month between now and September to allow for review of proposed updates.

18. Add “Process resource equivalents” to Intent resources and “Intent resource equivalents” to Process resources properties to allow linking between the resources.

19. Any spec changes not approved at the September TSC review will be deferred for the 1.3 specification (aside from gating items).

20. Alberto needs to define a descreening process, as the screening process may not be used to reinterpret screened data.

Proofing:

1. We need to update the description of the ColorSpaceConversion process to explicitly allow it to work on ByteMaps. Right now the text implies documents (pages).

2. Add wording to the Approval process where if you are providing a byte map that the assumption is that the process will display the byte map as a soft proof.

3. Make sure that the description of why the proofing and soft proofing processes were deprecated are sufficient and point to the application note.

4. The application note looks good, and pending examples, will be sent to Jim for an editorial pass.

5. We should only keep the last editorial note for an attribute (i.e. no modified in 1.1, modified in 1.2, modified in 1.3, …)

Color:

1. The eCommerce group has not been responsive in reviewing changes to Intent resources. The TSC needs to take a hand (Rainer to email and get them to look at the changes).

2. MediaIntent::Brightness needs to be reviewed by eCommerce.

3. We need to get ICC involved somehow with Papinet to vet parameters about paper. CIE* additions to MediaIntent are deferred to 1.3. GlossMeasurement addition also deferred (also GlossMeasurement would need to be able to be different for front and back of the media). Also MediaIntent::OpacityLevel.

4. eCommerce needs to review MediaIntent::Grade changes.

5. We should recommend that when a buyer supplies media to a printer, that they supply the Media resource specifically describing the media, and not a MediaIntent. We should then deprecate Media::Dimensions.

6. The HoleType clarification is rejected as we are removing references to SystemSpecified.

7. MediaColorDetails needs to be a string span, and add a note indicating that there is a one to one relationship between entries in MediaColor and MediaColorDetails. Approved pending eCommerce review.

8. Add Other to MediaIntent::MediaType.

9. We probably want to deprecate MediaIntent::MediaUnit if we add a Media element to allow you to specify customer supplied media. Also look at Continuous* in UserMediaType.

10. MediaIntent::ImageViewingStrategy is renamed ImageStrategy. Also the enumerations will be NoImages, LowResolution, and HighResolution.

11. ColorIntent::ColorManagementSystem should be moved to LayoutElement, as it is metadata about the CMS used for an individual file.

12. ColorIntent::ColorStandard deprecation of SWOP is rejected, as we are not deprecating items simply to have a better name. The working group needs to review the details of ColorStandard. Also, eCommerce needs to review the other deprecated items.

13. ColorIntent::ICCProfileSequence needs to move to LayoutElement.

14. All of the ColorIntent changes are bounced back to determine how to move (or copy) the appropriate attributes to LayoutElement.

15. The introduction to ScreeningIntent should be put into a generic introduction to Intent resources and how to specify process specifics.

16. ScreeningIntent::ScreeningType enumeration is reduced to just AM and FM.

17. AutomatedOverprintParams should have its description clarified and also needs to be coordinated with the RGBGreyToBlack in ColorSpaceConversion params.

18. ColorantAlias::MappingSelection should move to the Color resource, as each Color resource represents a ColorantName.

19. All ColorCorrectionOp changes are postponed until the working group finishes work on the changes.

20. Clarify the use of ColorPool and its description.

21. Demote ColorSpaceConversionOp, as it is no longer referenced from ColorIntent. Note that Ann thinks that it will be referenced by LayoutIntent.

22. ColorSpaceConversionOp::RenderingIntent - the SystemSpecified should be changed to ColorSpaceDependent and properly described. Please add a well-worded note about the change in default.

23. RGBGray2Black is deferred until after Automated Overprint issues are resolved.

24. ColorSpaceConversionOp::SourceRenderingIntent. If not specified should be the same as RenderingIntent. Also update the description to correspond to RenderingIntent.

25. ColorSpaceConversionOp::ColorPool is moved to the DeviceNSpace sub-element

26. Alberto needs to provide the appendix on SourceCS mappings.

27. ColorSpaceConversionParams::ICCProfileSequence is redundant to the process chain and should be simplified (you only need to indicate for the current instance where to get the destination profile). Sent back to working group.

28. Clarify the uses for the ColorSpaceConversionParams::FileSpec, but do not change the ResourceUsage name. Also update commentary to correspond to ICCProfileSequence changes.

29. LayoutPreparationParams::ImagePreScanStrategy would be in ImageReplacementParams, not LayoutPreparationParams.

30. Media::CIEWhitenessStandard we should only pick one standard. Ann picked TAPPI T 560.

31. Explain why Media::ColorName is deprecated (why ColorPool::Color is not appropriate for media).

32. Media::GlossMeasurement is renamed GlossValue.

33. Media::MediaColorValue is renamed LABColorValue.

34. Media::MediaColorStandard is defined to be TAPPI T 527.

35. Wordsmith ScreenSelector::AngleSecondary to make it clear that a single angle is often specified as the screening params. Also FrequencySecondary.

36. Add verbage to ScreenSelector::AngleMap to indicate that it is also valid for spot colors and add an appropriate example.

37. Move ScreenSelector::FrequencySelection to ScreeningIntent. Also add some more detail about how it might work.

38. Clarify ScreenSelector::SourceFrequency and SourceFrequencySecondary. We need to clarify how the source frequency is used to compare to the frequency being requested by the document, then to select the appropriate screen to use (Craig to clarify how SourceFrequency works).

39. Rainer still to clarify the XY coordinates for TrapWidth.

40. SystemSpecified color name is rejected.

Friday, June 20, 2003

General notes:

21. Keep the “new in 1.x” tags when editing the spec, but only the most recent of modified or clarified in …

22. Check percentages and make sure that they are all doubles (not integers).

23. Add to wording of definition of NoOp to indicate that it overrides all settings in the resource.

24. Add languages to schema data types.

25. Darmstadt interop is 15th through 19th of September. The TSC meeting starts Saturday the 20th, takes Sunday off, then continues Monday the 22nd through 24th.

26. Rainer will tbd’s from the color/digital printing and his changes into a single document with only tbd’s and leave the accepted items in the proposals to be sent to Jim for addition to the 1.3 draft. This will be done in 2 weeks.

27. Submission of a proposal for final review by the TSC has the requirement that the proposal has no tbd or issue items in the proposal; otherwise, the proposal will be rejected.

28. JDF examples and other proof of concepts must be final by the December meeting.

Digital Printing:

6. Color workflow note – rewrite introduction to ColorantAlias to sync with changes sent back on Thursday.

7. Color workflow note – ColorCorrectionOp – ranges should be changed from -100 to 100 integer values to -1 to 1 number values. Also clean up the wording of the introductory material.

8. ColorSpaceConversionOp – color working group should add reference to color space use cases application note.

9. DigitalPrintingParams::NonPrintableMargins – remove warning about using the feature (if this is necessary, then we shouldn’t put the attributes in JDF). Working group to discuss whether to put all for attributes into a child element rather than all 4 in DigitalPrintingParams.

10. InsertSheet::IncludeInBundleItem – clean up description and determine interaction with IsWaste.

11. InterpretingParams::PrintQuality changes are rejected as the changes come from an unfinished IPP proposal.

12. LayoutPreparationParams::HorizontalCreep and VerticalCreep are sent back for wordsmithing (both should have equivalent descriptions). The TSC does not believe that the description of restrictions are correct.

13. Media::DimensionName is not an attribute that should be used to define user interface. That is the purpose of localizations in capabilities. As such, it is rejected. A table should be added the spec with mappings of common sizes to point sizes, and should be normative.

14. Rejected clarification of previously deprecated Media::UserMediaType.

15. StitchingParams intro is sent back to coordinate systems working group to resolve.

16. We are not changing to the new language name spec until it finds its way into the XML schema.

17. Make the introduction to American weight explained into a table (Rainer).

Capabilities:

1. Add localization to all state variables to allow media sizes to be localized.

Rainer changes:

1. Need to add ICSVersions attribute to attributes of a JDF node. System behavior to propose naming convention.

2. Move physical resource QualityResult to appropriate resources (component, layoutelement, exposedmedia, media).

3. Define an xpath data type and make the deleted audit XPath have that datatype.

4. Quality control – explain how it is used in a JDF (the context). Also fix the inputs and outputs to use the correct resources.

5. Change to make SeparationControlParams optional in the Separation process is rejected.

6. Synchronize LayoutIntent::FinishedDimensions with digital printing proposal.

7. Synchronize LayoutIntent::Pages with digital printing proposal.

8. Change ComponentType to enumerations to allow qualification of both type of component and usage of component and flesh out description.

9. GatheringParams::StreamSequence is sent back to determine interaction with collation.

10. ImageSettingParams::FitPolicy is sent back to determine exactly what controls are needed and to see whether FitPolicy is appropriate.

11. InsertSheet::SheetFormat Duplicate needs to be sync’ed with digital print.

12. Define the Mime type of a PPF file.

13. Check definition of unbounded for all data types.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download