Off to a good start! I wanted to get you some initial feedback, although TBH I’m finding the document a bit difficult to navigate. The Use Case / Workflow examples are great but after that one is thrown into a bit of a puzzle to decipher a huge list of type/element definitions. Some ideas:
- Perhaps add a section between the Use Case and Data Model sections to introduce the way AMF works at a basic level, ideally using an example XML with some of the less important parts omitted for clarity.
- Perhaps make an alternate version of the data model diagram that trades off UML precision in order to be a little easier to read.
- Perhaps add a table of contents entry to the PDF for each element to make it easier to jump back and forth between elements.
- You might want to consider whether each element really needs to take up almost a full page.
My main feedback at this point is mostly relative to the Look file. I started a thread called “LMT color space tags” on Sept. 9th to discuss the to/from Look working space transforms. I’d like to reiterate my proposal that the
<toLookTransformWorkingSpace> tag be dropped and only the
<fromLookTransformWorkingSpace> be kept. (I’ll refer you to that thread for the motivation.) If that fails to convince, perhaps just make the “toLook” one optional?
Also, it would be helpful if the spec would clarify what is allowed with respect to user-supplied transforms and how that is supposed to work. For example:
- User transforms are allowed for Looks but are they also allowed for Look Working Spaces? It seemed the decision was “no” during one of the meetings, but the spec simply says that they must be Color Space Conversion transforms and then refers people to S-2014-002. Looking there it seems that CSCs may only be provided by the Academy. So it seems it is still a “no” but it is a lot of detective work required for such a crucial point – it seems like it should be spelled out more clearly.
- For LookFileType the spec says that “Valid transforms for this element are Look Transforms” and says to use a transformID and refers again to S-2014-002. But I suspect many readers will still be left wondering if user-supplied transforms are really allowed and if so how that will work.
- I believe the argument was that transformIDs are superior to a simple file name, but it is also less obvious how they are meant to be utilized. Clearly applications will need to associate the transformID with the file that contains the user look transform but there seems to be no discussion about how. Again this seems like a crucial topic and will undoubtedly be the basis for many of the interop problems encountered. Probably there is a desire to let people make this association in different ways, but to leave it totally as “an exercise for the reader” seems like asking for trouble.
I have not done a careful read at this point, but I did notice a few typo issues:
- In the UML diagram, I guess red means required and blue means optional but is that stated anywhere?
- In the UML diagram, the first instance of lookTransformWorkingSpace seems to use the wrong type (aces:fromLookTransformWorkingSpaceType rather than aces:lookTransformWorkingSpaceType).