FIMS v1.0: Comments on Feedback Sony Corporation Toshiaki Kojima Mizuki Kanada.

FIMS v1.0: Comments on Feedback

Sony CorporationToshiaki Kojima

Mizuki Kanada

Comment 1

From Majeed Arni <[email protected]>

Date Wed, 5 Oct 2011 04:35:14 +0900

Subject [FIMS-DEV] [Ebu-amwa-dev] Feedback on the FIMS Media SOA Version 1.0

Feedback&

Comment

1) Please add figure number for all figures.Yes, we agree.

2) 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.Yes, that's right.

3) In 9.2.1.1, description of notifyAt (tell what WSDL/operation does the URI need satisfy). I think it should be TransferMediaNotification.Unfortunately, we could not understand the meaning/intention.

4) In the WSDL/XS I see TransferMediaNotification but not defined or described in the PDF spec file.Yes, it is a cause of confusion.There is "TransferNotification" in the document. Because what's described in the WSDL is not Type but bind or operation name, TransferMediaNotification as an operation name is not incorrect theoretically.However, we have to admit that this would be the cause of confusion, and should be changed to TransferNotification.

Comment 2

From "Evain, Jean-Pierre" <[email protected]>

Date Sun, 9 Oct 2011 01:10:19 +0900

Subject [FIMS-DEV] [Ebu-amwa-dev] Feedback on the FIMS Media SOA Version 1.0

Feedback&

Comment

Proposed corrections / improvements in FIMS 1.0:

a) 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.Yes, we agree.

b) 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 timelinesThis should be discussed in Phase2?

Comment 3

From Jörg Houpert <[email protected]>

Date Wed, 26 Oct 2011 05:41:38 +0900

Subject [FIMS-DEV] [Ebu-amwa-dev] FIMS Specification - document separation

Feedback&

Comment

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. 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..*]. Is this something to consider for improving FIMS 1.0 ?

Yes, we agree. Changing maxOccur itself is easy, but we do not have a good idea how to describe these formats clearly.If you have a good idea, please let us know. We need to describe them in the implementers' Guidelines.

Comment 4

From Yoshiaki SHIBATA <[email protected]>

Date Thu, 27 Oct 2011 14:14:54 +0900

Subject [FIMS-DEV] [Ebu-amwa-dev] FIMS Specification - document separation

Feedback&

Comment

> - Part 2: Schema Description: see:Is the term "Schema" appropriate for the title while you've specified more than just the message structures ?I thought it is something like "Service Interface Definitions" ...Yes, we agree.

Comment 5-1 (1/2)

From Matthias Elser <[email protected]>

Date Fri, 28 Oct 2011 22:44:01 +0900

Subject [FIMS-DEV] [Ebu-amwa-dev] [EBU-AMWA] FIMS 1.0 Comments from IRT

Feedback&

Comment

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.“

[Page 26 of 122, Chapter 8.1.1.3, Sequence Diagram]*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.“Yes, we agree with all these comments, the observations made are correct.

Comment 5-2 (2/2)

Feedback&

Comment

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.Yes, we agree.

[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.We agree that this is an important function, but also think this is out of scope of FIMS because it is a mechanism of an orchestration system rather than a service interface.

Comment 6-1 (1/4)

From "Evain, Jean-Pierre" <[email protected]>

Date Sat, 29 Oct 2011 18:13:49 +0900

Subject [FIMS-DEV] FW: Comments on FIMS 1.0

Feedback&

Comment

(Forwarded) -----From: Mirko Zimmer [mailto:[email protected]] Sent: mardi, 25. octobre 2011 19:31To: Evain, Jean-PierreSubject: Comments on FIMS 1.0

- 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?! Yes, our original intention to describe Media Bus is to indicate the necessity of M-SLA rather than Media Bus itself.

- 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?! Yes, we agree. But the section 9.4 describes Service Consumer Interface not notification.

Comment 6-2 (2/4)

Feedback&

Comment

- Chapter 9: Media Service Communication: It would be very useful if the spec could contain example service requests, particularly for the service interface types.

This would be described in the "Implementers' Guidelines".

- 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?).

Yes, that's right.However currently what we have reached consensus on is only "destination".If you have a concrete idea, we would be pleased to review it.

Comment 6-3 (3/4)

Feedback&

Comment

With the idea of substituting our existing, self developed transfer service interface with a FIMS compliant transfer interface in my head there are 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? Yes, currently the transfer service only allows "copy" function. Both "moving" and "accessing media files…" should be removed.

- 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. Yes, you are right. But currently we could not find another way to specify "ftp user" and "password". If you have a good idea, please let us know.

- 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?!If the output file name is included in the URI, this can be possible. Anyway, description in the Implementers' Guidelines is desirable.

Comment 6-4 (4/4)

Feedback&

Comment

- 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).

Currently the transfer service supports only client-server based "copy" function.If you propose a detailed specification for "move" or "fxp", it will be appreciated.

- 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.

What's the definition of "local" transfer?In the current specification, the "copy" is possible as long as the file location can be specified by URI.

Comment 7-1 (1/2)

From "Evain, Jean-Pierre" <[email protected]>

Date Sat, 29 Oct 2011 18:15:06 +0900

Subject Re: [FIMS-DEV] Antw: RE : Comments on FIMS 1.0

Feedback&

Comment

(Forwarded) -----From: Mirko Zimmer [mailto:[email protected]] Sent: mercredi, 26. octobre 2011 18:11To: Evain, Jean-PierreSubject: Antw: RE : Comments on FIMS 1.0

There is another issue concerning the callback pattern and the MediaResponseType. I'll explain it in short:

The MediaResponseType ist 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. Yes, we agree. But we also think it will work even if it is complicated. Do you have any idea how to reduce the complexity?

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?!We could not agree with you more. That's why we have analyzed and organized all the option parameters.

Comment 7-2 (2/2)

Feedback&

Comment

An 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.Yes, we agree that message format can be simpler. On the other hand the message sequence will be complicated. It could be a disadvantage for the users who prefer to get all the information in one message.All in all, we prefer to keep the specification as it is.

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.We think it will not be a big difference because anyway a service has to describe the capabilities of both "job info" and "bmo".

Comment 8-1 (1/4)

From "[email protected]" <[email protected]>

Date Tue, 1 Nov 2011 03:15:15 +0900

Subject [FIMS-DEV] [Ebu-amwa-dev] [EBU-AMWA] FIMS 1.0 Comments from Quantel

Feedback&

Comment

First of all, the good bits:1) An extensible means to describe services.2) A clean state model.

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.If we understand correctly, we think the "authoritative source" is EBU Core.But we totally agree that there are too many metadata items whose usage is not clear in terms of the FIMS interface.

Comment 8-2 (2/4)

Feedback&

Comment

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 wou call into question why jobs have tasks rather than jobs being composed of other jobs?Yes, we agree. It would be best to adopt a two step approach. First, the specification should be finalized with the current structure. Then re-consider the structure without changing the contents.

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).Yes, we agree.

Comment 8-2 (3/4)

Feedback&

Comment

Some comments on the XML schema:

- Why use xs:sequence everywhere? What about xs:all that allows elements to appear in any order?We do not know the reason clearly but most probably this was to deal with the following constraints: - maxOccurs=“unbounded” is not allowed for the element inside <xs:all> - Adding element is not allowed if type using <xs:all> is inherited.>

e.g.

<xs:complexType name=“BaseType”> <xs:all> <!– ERROR: maxOccurs=“unbounded” is not allowed for the element inside <xs:all> <xs:element name=“element1” maxOccurs=“unbounded” /> <xs:element name=“element2”/> </xs:all></xs:complexType><xs:complexType name=“ExtendedType”> <xs:complexContent> <xs:extension base=“BaseType”> <!– ERROR: Adding element is not allowed if type using <xs:all> is inherited.> <xs:sequence> <xs:element name=“element3”/> </xs:sequence> <!– Adding attribute is allowed. <xs:attribute name=“attribute1”/> </xs:extension> </xs:complexContent/></xs:complexType>

Comment 8-2 (4/4)

Feedback&

Comment

- Why use attributes for numerator and denominator values? A pattern "<numerator>/<denominator>" would be less verbose?

Maybe because this structure has been defined in the EBU techMeta.

- 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.

We may need a discussion to make a consistent policy.

- 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.

Yes, we agree. But we need a discussion about what kind of data structure might be added.

- For true interoperability, UIDs need to be much more tightly defined than just strings ... e.g. GUIDs/UUIDs and UMIDS

Yes, we agree. The type may need to be changed like following:

<xs:simpleType name=“GUID”> <xs:restriction base="xs:string"> <xs:pattern value="\{[a-fA-F0-9]{8}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{4}-[a-fA-F0-9]{12}\}"/> </xs:restriction></xs:simpleType>

Comment 9-1 (1/2)

From Peter Guglielmino <[email protected]>

Date Tue, 1 Nov 2011 05:47:24 +0900

Subject [FIMS-DEV] Poposed Changes and Additions to Technical Metadata

Feedback&

Comment

(taken from the attached WORD file)OverviewThis document describes a proposed change to FIMS standard regarding the data representation of the required output technical specification. The proposal includes changes to TechnicalMetadataType data type and an addition of TechnicalMetadataType property to TransformProfile data type. This change would allow creation of a flexible and extensible model for specifying target file characteristics across a wide range of multimedia file formats.

ObjectiveThe current FIMS standard does not specify explicit transcoder target file parameters. The existing approach is to describe the target file parameters using a simple FormatID string value or by including vendor-specific profile information, for example, in “any” attribute of the profile. Although TechnicalMetadata information can be specified for a source file, the current standard does not provide TechnicalMetadata of the target file for a TransformMedia service.The approach of using FormatID values does not scale well with the addition of the new video and audio codecs. The method of specifying target format inside XML profile does not lend itself to intelligent decision due to the lack of strongly-typed information about the target file parameters.Having strongly-typed data representation of target format would allow the bus to send explicit instructions to TransformMedia service. This information would include all relevant parameters of the file transcode. FIMS service vendors would be able to use this strongly-typed information instead of defining a new custom profile structure for each new transcoder and codec.First of all, it is not exactly correct that a simple formatID value is used.In the current specification, TransformProfile inclues videoFormat, audioFormat and containerFormat as a part of TechMetada.Therefore some of information such as width, height, or samplingRate can be specified.Specifying codec uses the ID of EBU's TechMeta, and we are not sure how fast EBU can update their TechMeta.The fundamental question would be: who will be responsible for the format update?

Comment 9-2 (2/2)

Feedback&

Comment

Transform Profile ChangeThe goal for this proposed change is to specify target file format parameters for a TransformMedia service. Transform requests specify the target format information in the transform profile. It is therefore recommended to extend TransformProfile data type to include a property of TechnicalMetadata type.We think that the current specification has already realized the goal. VideoFormatType, AudioFormatType and ContainerFormatType as TechnicalMetadata are included in TranformProfileTYpe.Therefore we think only those parameters that are really required should be added.

TechnicalMetadataType ChangeThe latest revision of FIMS specification has removed TechnicalMetadata as a data type. It is proposed to add it back and start using it for describing media format parameters of target as well as source files.TechnicalMetadataType includes VideoFormatType and AudioFormatType properties with VideoFormatTypeVideoCodec and AudioFormatTypeAudioCode information, respectively. This proposal recommends new properties for VideoFormatTypeVideoCodec and AudioFormatTypeAudioCodec: Name, Vendor, Version, and Family. It also recommends extension to VideoFormatType: ResolutionWidth and ResolutionHeight (which may be different from DisplayWidth and DisplayHeight), BitRate, BitRateMode (variable or constant), ScanType (progressive or interlaced), ScanOrder (top-field first or bottom-field first), and NoiseFilter.Similarly, it is suggested to extend AudioFormatType to include Channels, BitRate, BitRateMode, SampleRate, and SampleSize. For further extensibility, it is recommended to add Any property to TechnicalMetadataType.1. Re-define TechnicalMetadataType which has been removed before. - We agree.2. Add Name, Vendor, Version, Family into the codec of VideoFormat/AudioFormat - If we understand correctly, this means to add codec by text? If so, it would be difficult to maintain interoperability?3. Add ResolutionWidth/Height (which is different from DisplayWidth/Height), BitRate, BitRateMode, ScanType, ScanOrder and NoiseFilter into VideoFormatType. - Adding parameters should be OK, but NoiseFilter seems AV Process rather than transform, so should be in Phase 2?4. Add BitRate, BitRateMode, SampleRate, SampleSize into AudioFormatType - Adding these parameters should be no problem, but SampleRate has been already defined.5. Add “any” into TechnicalMetadata for extension - In principle we agree, but this should be subject to the consistent policy applied to extension parameters.

Comment 10-1 (1/3)

From Peter Brightwell <[email protected]>

Date Thu, 3 Nov 2011 22:29:44 +0900

Subject [FIMS-DEV] FIMS 1.0 Comments from BBC R&D

Feedback&

Comment

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?Yes, we agree, and would like to start describing all this in the Implementers' Guidelines after the meeting.

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.See comment 6-1

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.Yes, that's right. We may need a further discussion. Our proposal is that at first let's finalize with the current style as v1, and then start organizing without changing contents.

Comment 10-2 (2/3)

Feedback&

Comment

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.Yes, we agree. We have added description regarding Service Description but no ideas yet for the registry.

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.No idea for the Service Discovery. Yes, we agree to omit the '/' before the '?'.

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.- Regarding extensibility, as we described in our comments, consistent FIMS policy should be created first.- Sorry, we could not understand the meaning of "plug-and-play" interoperability. Anyway as we have commented, the necessity of BaseProfile should be discussed.- We have already removed the sentence "Multiple entries...considered authorative" in our proposed document as we also could not understand the meaning and necessity.

Section 7.2.5: is this unfinished?We have described additional parameters on our proposed document.

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.See comment 8-2 (2/4).

Comment 10-3 (3/3)

Feedback&

Comment

Section 8.2.1: "ServiceDefinedTime type: the time defined by a service" - needs more explanation! Later the doc talks about event-based information, but this needs clarifying.We may describe the explanation on the Implementer's Guideline with some examples?

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.Yes, the term "Atoms" is appeared in section 7, and we have modified and removed the description in our proposed document.

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.)Yes, you are right. We have already removed the sentence in our proposed document.

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)?Yes, you are right. The current specification can only specify the format.The description should be modified according to the current specification.

Appendix 1: Missing referenceYes, needs to be added.

Comment 11-1 (1/3)

From "Evain, Jean-Pierre" <[email protected]>

Date Thu, 3 Nov 2011 22:29:44 +0900

Subject [FIMS-DEV] FW: Antw: FW: Comments on FIMS 1.0

Feedback&

Comment

(Forwarded)From: Mirko Zimmer [mailto:[email protected]]Sent: jeudi, 3. novembre 2011 08:55To: Evain, Jean-PierreSubject: Antw: FW: Comments on FIMS 1.0

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?!See comment 6-3