[Moims-ipr] [Fwd: [P189] New release of SAFE I/O Java/C++ API and Contol Books (safe-1-0-rc-13)]

Stéphane Mbaye stephane.mbaye at gael.fr
Fri Jun 9 22:05:01 EDT 2006


Dear all,

Please find hereafter a forward of the announcement of *ESA SAFE I/O 
Java/C++ API safe-1-0-rc-13 *and* SAFE Control Books* 
<http://www.gael.fr/safe> release.

In my opinion, the interests of this material for the DAI and IPR are 
mainly:

    * the *SAFE Control Book - Core Specifications* (Vol.1) that
      provides an example of XFDU specialization
    * the *SAFE Control Book - Recommendations for Specializations*
      (Vol.2) that provides guidelines for cascading XFDU specializations
    * the *ESA SAFE I/O C++ API *built on top of the *ESA XFDU I/O C++
      API* <http://www.gael.fr/xfdu> that complements all NASA/ESA/CNES
      *Java* APIs or applications.

Such as announced below, I will provide you with a password for the user 
*harm* in a successive e-mail.

Looking forward to seeing you at Rome
Cheers
Stéphane

-------- Original Message --------
Subject: 	[P189] New release of SAFE I/O Java/C++ API and Contol Books 
(safe-1-0-rc-13)
Date: 	Sat, 10 Jun 2006 03:34:50 +0200
From: 	Stéphane Mbaye <stephane.mbaye at gael.fr>
Organization: 	GAEL Consultant

	

	



Dear All,

we are pleased to announce the release of the *ESA SAFE I/O Java/C++ API 
safe-1-0-rc-13*. It is available at http://www.gael.fr/safe . Access to 
this site is restricted to the user *harm* with a password to be 
provided in a successive mail.

_*Release summary:*_

   * *First issue* of the overall set of 19 *SAFE Format Control Books*
     including ESA RID fixes. The documents are now available as
     version 1.0 without draft watermark.
   * The 13th release candidate improves the C++ API with a *complete
     support of exceptions*. Close to 20,000 lines of C++ code have
     been reviewed and rewritten for this purpose. The C++ API
     documentation took advantage of this period to be entirely
     reviewed. The activity was also focused in getting the code closer
     to the *BSSC2000(1)i10 C++ coding standard* issued and recommended
     by ESA.
   * Both Java and C++ implementations are *conforming the XFDU
     specifications v1.9* issued for agency review in the framework of
     the CCSDS IPR and DAI working groups.
   * The software now requires a *Java version 1.5.0 or higher*.
   * The distribution no longer includes the SAFE Transformers
     dedicated to the conversion of native formats to SAFE
     specifications e.g. ENVISAT or ERS converters. The SAFE
     Transformers have now their own distribution means with a separate
     configuration identification and control.

_*Special Compatibilty notes:*_

This new release candidate is fully compatible with all previous Java 
codes. For C++, the following items should be modified or verified:

   * esa::xfdu::object::metadata::MetadataObject::getMetadataWrap() no
     longer returns a pointer to a MetadataWrap class. Actually, since
     several wrapping around are allowed in an XFDU Metadata Object, it
     was necessary to return a Collection of MetadataWrap objects c.f.
     MetadataObject::getMetadataWrap() API documentation
     <http://www.gael.fr/safe/site/apidocs/c++/html/classesa_1_1xfdu_1_1object_1_1metadata_1_1MetadataObject.html#a9>
     for further information.
   * esa::xfdu::object::metadata::DefaultMetadataObject no longer
     accepts a classification parameter as an integer to be selected
     from a fixed enumerated list. This to allow automatic support of
     further XFDU XML Schema updates. A XML Schema allowed character
     string shall be provided e.g. "CONTEXT", and will be controlled
     during Schema validation c.f. DefaultMetadataObject API
     documentation
     <http://www.gael.fr/safe/site/apidocs/c++/html/classesa_1_1xfdu_1_1object_1_1metadata_1_1DefaultMetadataObject.html>
     for further information.
   * esa::xfdu::object::data::FContent detailed constructor no longer
     accepts a content_type parameter as character string. 0 or 1
     integer value shall be provided instead c.f. FContent API
     documentation
     <http://www.gael.fr/safe/site/apidocs/c++/html/classesa_1_1xfdu_1_1object_1_1data_1_1FContent.html>
     for further information.
   * When using both XFDU I/O and SAFE I/O library, the dual
     definitions of DefaultDataObject may be declared as ambiguous for
     C++ compilers. An explicit reference to
     esa::*xfdu*::object::data::DefaultDataObject or
     esa::*safe*::object::data::DefaultDataObject may be required.

*_New features and changes:_*

   * The main improvement of the present release is focused on the
     handling of exceptions in the SAFE I/O C++ Wrapper. The exceptions
     are all subclasses of *runtime_error* and *logic_error* standard
     classes of C++. All are broken down in three main categories: C++
     Standard Exceptions, *JvmDriverException* and
     *JvmDriverJavaThrowable,* both latter inherited from the
     *esa::xfdu* namespace c.f. XFDU I/O C++ Wrapper
     <http://www.gael.fr/xfdu/site/apidocs/c++/html/index.html>. See
     FAQ <http://www.gael.fr/safe/site/faq.html#c__-exceptions> for
     further information on how exceptions should be managed while
     using the SAFE I/O C++ Wrapper.
   * The C++ header file *Safe.h* has been split in several components
     e.g. *AcquisitionPeriod.h*, *QualityInformation.h* etc. The change
     leads to a more comprehensive code but has no impact on the
     applications that still have to include the unique *Safe.h* header
     file.
   * The SAFE I/O library now depends on XFDU I/O library 1-0-rc-10
     <http://www.gael.fr/xfdu> supporting full C++ exceptions handling
     c.f. XFDU I/O C++ Wrapper and implementing several fixes to cope
     with the latest XFDU working draft issued by the CCSDS i.e. XFDU
     specifications v1.9 issued for agency review in the framework of
     the CCSDS IPR and DAI working groups.
   * The SAFE I/O library now depends on DRB 2-2-rc-12 c.f. DRB Web
     site <http://www.gael.fr/drb>. The Jar archive is included in the
     distribution.
   * The SAFE I/O library now depends on Xerces 2.8 instead of the
     former 2.7.1. Although this latter release include several
     improvements it does not fix the drawbacks encountered while
     parsing XML Schema's with  cascading or multiple  redefinitions.
     The Jar archive is included in the distribution.
   * *AcquisitionPeriod::AcquisitionPeriod()* accepts default values as
     parameters. It is no longer mandatory to provide stop time at
     construction as authorized by the specifications.
   * *CorruptedCause::CorruptedCause()* detailed constructor now
     accepts default values. It is no longer mandatory to specify an
     "other type" or a severity rate. They are both defaulted to an
     undefined value.
   * *Location::Location()* detailed constructor now accepts default
     values. The position parameters e.g. *after,* *preceding,* etc.
     are no longer mandatory and are defaulted to an undefined value.
   * *CorruptedElements::CorruptedElements()* detailed constructor now
     accepts default values. Element count and corruption evidence are
     no longer mandatory.
   * *Safe::moveTo(char* destination)* and *Safe::moveTo(char*
     destination, int cascade)* have been merged in the same operation.
     The second parameter i.e. *cascade*, is now optional with a
     default value set to 0 i.e. false meaning that files attached to
     the manifest are not moved to the destination directory by default.
   * *ContentUnit::addDataObject(DataObject* data_object)* and
     *ContentUnit::addDataObject(DataObject* data_object, char*
     pointer_id)* operations have been merged in a single equal to the
     latter with an optional *pointer_id* parameter. The default value
     is null.
   * *FContent::FContent(char* identifier,int content_type,char* data)*
     of the C++ wrapper, the data and content_type parameters have been
     swapped to allow a default value for the latter i.e. default value
     of content_type has been set to 0, corresponding to XML data type.
   * The more detailed constructor of *Reference::Reference()*
     considers all its parameters as optional.
   * The more detailed constructor of
     *DefaultMetadataObject::DefaultMetadataObject()* considers all its
     parameters as optional.

_*Fixes:*_

   * The *Safe::toString()* operation returns actually the string
     processed by the Java API. Previous versions were not correctly
     converting the Java String expressed in UTF-16 to UTF-8 character
     encoding supported by the C++ *char**.
   * *Safe::save(int validate)* actually saves the manifest document
     has for the *Safe::save()* and equivalent method in the Java API.
     A wrapping error has been fixed.
   * *Safe::getContentUnit()* actually return null when no Content Unit
     matches the identifier provided in parameter. Former releases
     returned an empty Content Unit not existing in the input package.
   * Fixed incorrect wrap around of *Safe::setSchemaLocation()*
     operation. Fixes *ByteStream::setFContent()* that assigned a C++
     class to the Java layer instead of its referenced Java instance.
   * The *MetadataObject::getMetadataWrap()* operation now actually
     returns a *Collection* object instead of a MetadataWrap. This
     fixes the inconsistency with both the Java implementation and the
     documentation. It however makes the current C++ wrapper
     incompatible with the former release candidates.

_**__*Removed features:*_

   * The distribution no longer includes the SAFE Transformers
     dedicated to the conversion of native formats to SAFE
     specifications e.g. ENVISAT or ERS products. The SAFE Transformers
     have now their own distribution means with a separate
     configuration identification and control.
   * The distribution no longer depends on indirect dependencies from
     DRB e.g. JAI codecs. Users willing to benefit from the overall DRB
     functionality shall refer to the DRB Web site
     <http://www.gael.fr/drb> for a complete configuration. Otherwise,
     standard use of SAFE I/O does not require these dependencies.
   * *ContentUnit::addMetadataObjectReference()* operation is now
     deprecated. This operation no longer wraps any Java code and
     therefore, does nothing but returning immediately. The only way to
     assign a Metadata Object to the Content Unit is to provide its
     identifier at construction c.f. *ContentUnit()* parameters as
     *dmd_id*, *rep_id* etc.
   * *ContentUnit::addReference()* operation is now deprecated. This
     operation was created for supporting the *XFDUPtr* mechanism for
     referencing external XFDU packages. This mechanism still needs
     clarifications in the official XFDU specifications at the time of
     implementing. The operation, therefore, no longer does anything
     but returning immediately.
   * *ContentUnit::moveTo()* operation is now deprecated. This
     operation was wrapping around a Java operation that should have
     remained protected and not exposed to the C++ layer. The operation
     no longer does anything but returning 1 immediately.
   * *ContentUnit::getReferences()* is now deprecated. This operation
     is deprecated for the same reasons as *addReference()*. It no
     longer does anything but returning null (0).
   * *DataObjectPointer* class is now considered as a class private to
     the *esa.xfdu.map* Java package and, therefore, no longer exposed
     to the C++ wrapper.
   * One of the *Reference::Reference()* constructor has been removed
     since its was becoming redundant with the most detailed
     constructor that now allows all parameters as optional.
   * Several the *DefaultMetadataObject::DefaultMetadataObject()*
     constructor has been removed since they were becoming redundant
     with the most detailed constructor that now allows all parameters
     as optional.
   * The *MetadataObjectReference* class and all references to it, have
     been removed from the entire library.


Do not hesitate to provide us with your comments.
Best regards

Stéphane Mbaye
GAEL Consultant


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ccsds.org/pipermail/moims-ipr/attachments/20060610/bfa06567/attachment.htm


More information about the Moims-ipr mailing list