Digital Item Processing (DIP) Break Out Group – met all week
Where:
Room 208-2
When:
Mon
17.00-18.00 (MDS room)
Tue
9.00-11.00
Tue
14.00-15.00
Wed
11.00-15.00
Thu
0900-1600
21Mandates
Dispose of NB comments on the FCD of DIP.
In particular we need to report an assessment of the C++ DIXIOs technology as to whether it is stable enough for inclusion in the FDIS.
Prepare text for RFC for registration of a DIM MIME type.
Produce text of the FDIS of DIP - with editing period.
Produce two page description of DIP for the convenor.
22Discussion of inputs in MDS group – Monday 1615-1700
Declaring DIMs and DIXOs – m11890
A concern was raised with forcing the identification of the DIM at the level of the Item.
One argument is that (as a User of DID), for DIP a DIM is an Asset. An Asset is represented by an item. Therefore the DIM should be identified at the level of the Item.
However it is noted that resources are Assets also. They are the Assets that make up an item (which is also an Asset)
The concern is that forcing identification of the DIM at the Item level may restrict the usage of DIP within DID (that is it forces only a single identifiable DIM/DIXO per item).
Proposal for C++ DIXOs – m11891
It was noted we need to be clear about what DIP will be standardizing (for example Java includes the execution environment, but for C++ there is no such standard execution environment)
Concern was raised about adding such a large change to the FDIS. The alternative is to start an Ammendment.
It was also noted that reference software would be needed for ensuring the proposed calling mechanism for C++ DIXOs works
The issue of requiring bit equivalent Resources in a Component was discussed. This impacts J-DIXOs in that only bit equivalent classes, jar file, or directory can be contained in a Component. This will mean that the example in C.3.4 is not valid. It will be updated to remove the directory based resource.
Also the identifying of the DIXO (DIM) was discussed.
It was pointed out that to exchange a DIXO (DIM) requires it to be in an Item. Therefore the identifying should be at the Item level.
Directory based J-DIXO classes
The issue about having a directory as a Resource was discussed (BNB comment)
The question as to whether a directory can be considered a didl:Resource. We need to discuss this in MDS.
If it is retained it should be modified such that the directory is identified in a terminal independent way.
C++ DIXOs
It is not clear if the proposal is to include C++ source code or compiled C++ classes. The intention is to include compiled C++ classes.
This is an issue as compiled C++ code is not platform independent.
Should DIXOs include specification of the execution environment (e.g. what are the security implications of the execution environment for C++ DIXOs)? This might not possible for C++.
It was noted that the text was based on the J-DIXO text, and included some things that are defined in the Java context but not in the C++ context (for example there is no standard for what is a compiled C++ object).
What C++ is being proposed to be included? ANSI C++, etc.
If including compiled C++ objects, then it is strictly not C++ but the compiled machine code.
We need to be clear on the motivation for C++ DIXOs (or compiled languages DIXOs in general for which there is no standard for the compiled code). Does it satisfy the requirements for DIXOs and DIP in general?
A possible option is to specify only the C++ bindings for DIBOs and be silent on other things. But then how would that be useful?
Thu afternoon
No outright objection of having C++ DIXOs.
But do we need more time to study the complete technical solution and implications?
There are no requirements for platform-independent DIXOs.
But will it effect the platform-independence of DIMs? If my DIM calls a DIXO that can't be run on a given terminal, then is the DIM platform-independent? The answer is somewhat of a semantic debate.
It could be just left to the DIXO implementer to say "my DIXOs run on blah platform" only.
Do we need to "profile" C++?
Java based (or Perl based, for example) DIXOs and ECMAScript DIMs can be verified at run-time. This cannot be done for C++ object code. The verification is a matter of trusting the supplied of the DIXO.
Does DIP need to specify how to obtain trusted DIXOs?
What is the motivation?
To be able to talk to the DIP engine from a C++ application.
If only the C++ bindings are defined, you could include a C++ object as an executable resource and that could access the DIP engine via the binding.
But how does it obtain access to these bindings?
A possibility is define the DIBO API in IDL.
One option is to adopt the C++ bindings and a DIBO to get the C++ implementations. But what would you call to get that DIBO.
If time is given to study this, we may be able to come up with a more generic mechanism applicable to many compiled languages.
Developing a generic solution may just bring up the same issues and questions for many languages.
A generic execution environment might not be something that can be specified.
Recommendation: Start an amendment and further refine the technical solution.
