Comments Received on FIMS v1.0

1. Comments Received on FIMS v1.0 7 November 2011

2. Comments received on FIMS 1.0 • IBM - 4 Oct • EBU - 8 Oct • Cube-Tec International - 25 Oct • HR - 25 Oct, 26 Oct, 3 Nov • IRT - 28 Oct • IBM/Bloomberg - 31 Oct • Quantel - 31 Oct • Sony - 1 Nov • BBC - 1 Nov

3. IBM - Majeed Arni 4 Oct 11 • Please add figure number for all figures. • In section 8.1.1.3 (first figure there) and section 8.1.3 last figure. - Instead of manageJob, I think it should be queryJob to get the status. • In 9.2.1.1, description of notifyAt (tell what WSDL/operation does the URI need satisfy). I think it should be TransferMediaNotification. • In the WSDL/XS I see TransferMediaNotification but not defined or described in the PDF spec file. - all agreed, will fix

4. EBU - Jean-Pierre Evain 8 Oct 11 • Add a section in the specification with the namespaces used in XSD and WSDL files. Define evolutionary namespace structure as new namespaces will be needed for e.g. phase 2. - add guidelines • technical metadata only allows the description of basic/simple business media objects - the proposal is to encapsulate this technical metadata in a "businessObject" and associated "part" to allow the description of parts / segments of content as well as technical parameters along specific timelines - to be considered by metadata drafting group

5. Cube-Tec - Jörg Houpert/Denis Pingin 25 Oct 11 Within FIMS 1.0 we would like to describe (in terms of metadata) a media container that has two or more video (or audio) tracks where each track has its own format (e.g. DTS + AC3 + PCM). The videoTrack (or audioTrack) data type does currently not allow to specify such a format. - to be addressed by metadata drafting group, need examples (Jorg, Roger) The cardinality of videoFormat or audioFormat is [0..1]. It would be just sufficient to changes it to [0..*] In EBUCore it is already designed this way [0..*] - to be addressed by metadata drafting group

6. HR (1) - Mirko Zimmer 25 Oct 11 - Chapter 5.5.3 I think, the Media Bus is a product-specific extension and it is not a required component for an architecture implementation?! As part of the spec it suggests, that you need this kind of component for AV/file exchange (in addition to the transfer service?) or that the "middleware" is not just a middleware, but also responsible for active file exchange (in competition to the transfer service?). But this is more or less a matter of taste?! - agree. But it's just informative.- Chapter 8.1.1.2: This is an essential pattern for the FIMS services. The FIMS specific way of implementing this communication pattern would be more traceable if there is a pointer to chapter 9.4 and a reference/hint to the notification binding of each service wsdl?!  - review text to see if we can clarify - Chapter 9: Media Service Communication: It would be very useful if the spec could contain example service requests, particulary for the service interface types.Implementation Guidellines

7. HR (2) - Mirko Zimmer 25 Oct 11 - Chapter 9.3.1:  Transfer Service Interface. Basically I think, that this service definition is too abstract in V1.0! Beside of the job and the bmo parameters, the transfer request contains the transfer profile only, which defines just a transferAtom URI for the destination. All the transfer (static and dynamic) configuration parameters must be filled in the "any" section and therefore it is not specified. This allows us to do almost anything with the transfer interface and it will be more or less a "vendor specific" thing. Switching to a new service implementation will be not so easy. It will be difficult to define the responsibility boundaries to other services too. Our understanding of the transfer service is to offer file exchange capabilities between servers with standard protocol support as described in chapter 7.2.3.2, thus the transfer service differs from other services like a source management service (extended source information service) or an export service (maybe this two new services are phase 2 candidates?). - agree, but this is what we have now for v1.0. Maybe future work?

8. HR (3) - Mirko Zimmer 25 Oct 11 With the idea of substituting our existing, self developed transfer service interface with a FIMS compliant transfer interface some concrete questions:  - What means "[....] accessing media files" in the first paragraph of chapter 9.3.1? Beyond the transfer facility of files what kind of functionality should be supported? - agree. delete - How can we pass connection information for source and destination locations to the service, ftp user and password for example. It is possible to encode this in the authority part of the URI, but this is not the preferred way. - happy to discuss your suggestion! - Sometimes, it is necessary, that a file must be renamed during the transfer. For this case the transform service defines the outputFileNamePattern, but it is not part of the transfer request?! - reflect as error? no change in 1.0 - How can we provide transfer mode parameters like move or copy mode. Another use case is to distinguish between fxp transfer or piped ftp transfer. Because of some security restrictions, fxp is not always allowed (for external delivery for example). - not for 1.0. A new feature can be requested for the future. - Should the transfer service support a "local" move or copy mode for moving files inside a location? Or is it part of the Source Information Service? For a transfer request the source and destination locations are equal in this case.- done already

9. HR (4) - Mirko Zimmer 26 Oct 11 There is another issue concerning the callback pattern and the MediaResponseType.:The MediaResponseType is a pretty complex xml schema. For example in case of a transfer notification my soapUi produces a complex xml instance from the schema, see below. The spec says, that this callback has to be sent to the Service Consumer by the service! The service consumer must be able to "understand" this callback with all optional or mandatory fields and combinations of the fields! On the other side, the service capability for this callback must be well documented. Not all service implementors will support all fields?! If it is not clearly described, you can create a strong dependency between the service implementor and service consumer. Possibly, the interoperability between service implementors will be decreased?! consider during re-factoring; could mention in implementation guidelinesAn alternative could be a stronger separation of job status information (operation info) and media object information (bmo, bmresultmap) in the reponse capabiliy of a service. For example, the transfer notification (the callback) could contain only the operation information: job with id xy has finished with state 'Completed'. If the service consumer is interested in more media object related information, he can call the already defined TransferMediaStatusBinding/queryJob interface in a next step.We use this way of separating job and information data in our quality control service adapter. The VIO process sends a job to the quality control service. The job is acknowledged. After completion, the service sends a callback with pure job state information (check successfull, no errors for example) back to the platform. After this, the process instance uses a method like "get report" to read the complete report. In my opinion, the service capability concerning the response data can be better described by the service provider in this way. The service consumer has the freedom of choice to use the queryJob interface for additional data or not. The drawback is the second call to the service of course. 

10. HR (5) - Mirko Zimmer 3 Nov 11 Asynchronous request response pattern: The BaseRequestType defines the notifyAt parameter (AsyncEndpointType), which should contain the callback address (chapter 9.2.1.1). Additional to the callback address we need a user/password information to authorize the callback client (the service). At the moment, there is no option for that and we must configure a default user/password for the service implementation. Maybe there should be such an option in the BaseRequest/AsyncEndpointType? On the other side, putting the (uncrypted) user/password information in each request could be a bigger security issue?! - discussed. up to user.

11. IRT (1) - Matthias Elser 28 Oct 11 Errors: [Page 12 of 122, Chapter 5.5.3.1, Paragraph 3] "This corresponds to SLA in a conventional IT-based SOA system and is referred to as M-SLA. Because the detailed specifications of M-SLA need to be harmonized with SLA, this will need to be need to be discussed by the FIMS Task Force at a later date in accordance with SLA developments." - beyond scope of 1.0 [Page 26 of 122, Chapter 8.1.1.3, Sequence Diagram] - all editorials, agreed *response := manageJob("status", jobID) , should be queryJob [Page 29 of 122, Chapter 8.1.3, Sequence Diagram] *responseWithFault := manageJob("status", jobID) , should be queryJob [Page 120 of 122, Chapter Appendix 1.1, Clause 2] "As described in Section 8.2.2, a pipelined media service within a service can be realized using profiles. Error! Reference source not found. shows an example of extended pofile usage where two Capture (Transform) profiles are used to create main stream essence (J2K + MXF) and proxy essence (AVC + MP4) with AV Process."

12. IRT (2) - Matthias Elser 28 Oct 11 Remarks: [Page 18 of 122, Chapter 6.2.2] The ListFilterType should be able to filter on ALL JobStatusCodes separately (queued, running, paused, completed, canceled, terminated, failed, cleaned, unknown)  instead of grouping  to "queued", "active", "finished" and "failed". According to the annotation in baseMediaService-V1_0_0.xsd, the JobStatusCode  "canceled" is not in any of the four grouping. - ask for proposal [Page 26 of 122, Chapter 8.1.4] How does the framework allow retry of failed services? How does the framework allow the definition of compensation mechanism ? Maybe this should be described a bit more detailed. - out of scope

13. IBM/Bloomberg - Peter Guglielmino 31 Oct 11 We have compiled a set of suggested changes and additions to the technical metadata that we would like the FIMS members to review and comment on. - See: proposed fims output technical metadata modifications V2.docx - TechMetadata- discuss, also EBUCore - See: EBU_CORE_FIMS_TechnicalMetadataType_Bloomberg_EBU_rev.zip

14. Quantel (1) - Richard Cartwright 31 Oct 11 The following comments about FIMS are mainly from the perspective of a detailed review of the XSDs provided rather than the specification document. As such, they are concerned with technical constraints imposed on an embodiment of FIMS by the architecture of its specification that would limit current or future specifications rather than on whether the specification is fit for its business purpose. As such, these are fundamental architectural concerns that may be difficult to address pragmatically in the short term. However, I believe the group needs to be aware of their existence and significance as this work is intended as a framework platform. First of all, the good bits: 1) An extensible means to describe services. 2) A clean state model.

15. Quantel (2) - Richard Cartwright 31 Oct 11 At a high level: 1) FIMS lacks overriding architectural principles, such as "a single authoritative source for any item of metadata", and as such messages are overloaded with too much information. I believe that the specification encourages metadata to travel with command and control messages in an RPC-style on the assumption that the only way a target system will known about a source system's metadata is through the metadata contained in the message. This is a tight coupling that is brittle to metadata changes (multiple copies of data everywhere) and will lead to all kinds of problems where architectures where every island is sent everything just in case it is needed. Far better to have clean command and control interfaces and separate, loosely-coupled metadata services. 2) A clean data model is not clearly specified or embodied anywhere (e.g. UML class diagram). This makes implementation of a Model-View-Controller application or RESTful set of resource-oriented services hard. In fact, it is my view that lack of a clear data model is over complicating the specification and XSDs and makes them difficult to extend. FIMS has a few primary entities (Job, Queue, BMObject, BMFolder, Metadata, ServiceCapability) that could be brought out in a simple model. Data model analysis would call into question why jobs have tasks rather than jobs being composed of other jobs? 3) Some concepts are mixed together - what is state and what is a command (e.g. asking for a Queue's status vs starting and stopping it) mixes view and control. A view of a folder structure is often a tree hierarchy (view) but a filing system data model is rarely implemented that way ... a child points at its parents. As another example of this, a BMObject may be described by many different metadata sets depending on the application's it is used in (contracts vs presentation). Agreed to form sub-group to consider impact of new proposal

16. Quantel (3) - Richard Cartwright 31 Oct 11 Some comments on the XML schema: • Why use xs:sequence everywhere? What about xs:all that allows elements to appear in any order? - no issue • Why use attributes for numerator and denominator values? A pattern "<numerator>/<denominator>" would be less verbose? - EBUCore, not an issue • In fact, why use attributes at all? You could achieve everything in FIMS with just element values and this is a much more consistent approach. - no reason to change • The time type prohibits the use of 30 or 36 hour clocks, common in scheduling applications where the broadcast day starts at 6am. Best to either use strict SMPTE 12M timecodes limited to 23:59:59:29 combined with a date or allow for values up to 99:59:59:29. - agreed, can do • For true interoperability, UIDs need to be much more tightly defined than just strings ... e.g. GUIDs/UUIDs and UMIDS - agreed, can do • - plus editorials and state issue (offline)

17. Sony - Toshiaki Kojima 1 Nov 11

18. BBC (1) - Peter Brightwell 1 Nov 11 • Document needs an introduction that provides some hand-holding, else it can come across as somewhat impenetrable. This could be the developer guide that's been discussed, and it needs to have some simple examples, perhaps an overview of the data model. How simple can FIMS really be? • Can we give a minimal example showing a sequence of HTTP requests and responses? •  Support proposed separation of document into general, base and service as proposed in recent emails from Sony and Avid. •  Terms such as "ESB" and "Media Bus" would seem to suggest a particular approach to implementation, but I don't think that's what we're trying to tell people. This could be helped with the minimal examples.- agreed •  Clarity on how FIMS can support RESTful interaction style, with decoupling of command logic from metadata. There appears to be quite a RPC-like nature to many parts of FIMS (esp in section 9.2), which would complicate development in an MVC environment (which is what we are currently doing). See also Richard Cartwright's recent comments on this, and my email of Sept 29th. • - will be covered by Richard's sub-group

19. BBC (2) - Peter Brightwell 1 Nov 11 • Section 7 could be rearranged so that the explanation of what it's about (in 7.2) comes first, then going into the details of the registry and description documents. • 7.2 Service Description to come first. 7.1 Service Registry is out of scope of v1.0 •  In 7.1.1, can anything be said about a convention for the initial HTTP GET, or some other method to help bootstrap discovery? Also the '/' before the '?' in two of the examples should probably omitted. - agreed, but it's deleted anyway •  Although it's good that some specific standard transfer classes are enumerated in 7.2.3.2, something should be said about extensibility, in case the reader to thinks that their (possibly proprietary) transfer technology couldn't be using for a FIMS-mediated transfer. Also perhaps something should be said about "plug-and-play" interoperability, eg a baseline profile that we can expect implementations to support. (Or is that being unrealistic, it doesn't seem to have worked for DLNA...). • Also in this section, the part "Multiple entries...considered authorative" needs explanation. - have asked Lewis to clarify •  Section 7.2.5: is this unfinished? • - this is in hand

20. BBC (3) - Peter Brightwell 1 Nov 11 • Section 8.1.9: checking the status isn't really a task as such. I think Richard made a similar, but better, comment about this. • Section 8.2.1: "ServiceDefinedTime type: the time defined by a service" - covered, also Service Description discussion later - needs more explanation! Later the doc talks about event-based information, but this needs clarifying. •  Section 8.2.2: Atoms is defined here, but used several times earlier in the doc - this could be tackled by reorganisation? The examples in this section would be useful earlier on.- check that Atom is defined before its first occurence •  Section 9.3.1: This talks about a "target agent" but the spec doesn't explain what this is or its context. (I think this is inherited language from SMPTE ST 2032, where it has a specific meaning for point-to-point file deliveries.) - done, deleted •  Section 9.3.2.6.1: This says the profile "may specify how [the media format] is produced." How do this happen (or does this really mean specifying the technical parameters of what is produced)? delete last after "output". •  Appendix 1: Missing reference - editorial, needs to be fixed