data.web.releaseNotes-2.2.0.jsp Maven / Gradle / Ivy

Go to download

Show more of this group Show more artifacts with this name
Show all versions of ddmsence Show documentation

DDMSence (pronounced "dee-dee-em-Essence") is the only open-source Java library that fully supports the DoD Discovery Metadata Specification (DDMS).

The newest version!



	DDMSence: What's New in DDMS 5.0 / DDMSence 2.2.0
	
	


<%@ include file="../shared/header.jspf" %>

What's New in DDMS 5.0 / DDMSence 2.2.0

The table below describes the major changes in DDMS 5.0. For additional details, refer to the Release Notes bundled with DDMS 5.0.


DDMS 4.1 DDMS 5.0

	The ddms:resource element is a "metacard". The metacard is a full-fledged, top-level element containing all of the details about a described asset.
	The ddms:resource element is an "assertion" in the IC's Trusted Data Object (TDO). The assertion by itself is insufficient for describing an asset, and 
		the entire TDO record is needed to fully understand what is being described.


	A metacard has five core sets (Metacard Info, Security, Resource, Summary Content, and Format) and an Extensible Layer.
	An assertion has four core sets (Metacard Info, Resource, Summary Content, and Format) and no Extensible Layer. Security information has moved to the Enterprise Data Header (EDH)
	of the TDO. Extensions would be modeled as standalone assertions in the TDO, separate from the DDMS discovery assertion.


	Cardinality of DDMS components is enforced in the XML schema.
	Cardinality of DDMS components have been removed from the XML schema, to allow the schema to be used in alternate contexts. The specification still identifies some components as Mandatory
	for discovery.


	Some Mandatory string components were allowed to have a nonsensical value of an "empty string".
	DDMS now requires all Mandatory string components to have a minimum length of 1.


	A GML profile and a custom ddms:postalAddress defintion are used for geolocations.
	Geolocations are handled with the Time-Space-Position Information specification.
	ddms:boundingBox, ddms:verticalExtent, gml:Point, and gml:Polygon are replaced by comparable TSPI shapes.


Table 1. Major Differences in DDMS 5.0

These changes have impacted DDMSence 2.2.0 in the following ways:

	The DDMSReader class works on both metacards and assertions. The DDMSReader cannot interpret an entire Trusted Data Object -- you will need to extract
	the ddms:resource assertion before it can be loaded into DDMSence. Assertions created by DDMSence are incomplete on their own, and are intended for insertion into a TDO record.


	Because DDMSence was already enforcing that Mandatory components also be non-empty, the cardinality and empty string changes in DDMS 5.0 have no impact.


	DDMSence 2.2.0 contains a new package of classes for TSPI shapes and addresses. The TSPI specification is incredibly complex and multi-layered, and it is unclear how much 
	value a complete implementation in DDMSence would provide for discovery use cases. For this reason, shapes and addresses in the TSPI namespace are simple wrappers around the
	raw XML definition of the TSPI component. This is actually a step back from the GML shapes provided in older versions of DDMSence. As use cases refine and more organizations 
	adopt DDMS 5.0, I will revisit these components to determine whether a stronger solution would be useful.


	DDMSence 2.2.0 is backwards compatible with all versions since 2.0.0, with three minor exceptions:
		
			The method, BoundingGeometry.getPoints() has been renamed as BoundingGeometry.getGmlPoints() to eliminate confusion between GML points and TSPI points.
			The method, BoundingGeometry.getPolygons() has been renamed as BoundingGeometry.getGmlPolygons() to eliminate confusion between GML polygons and TSPI polygons.
			The constructor, DDMSReader(), now requires a specific DDMSVersion as a parameter. Each reader instance is tied to a single version of DDMS. 
			You will need to create a separate DDMSReader for each version of DDMS XML file you intend to load. The sample applications have instructional code for this.


		
	
	The API documentation has been updated with helpful summary information on each class. The new standardized format should make it easier to understand how
	components have changed through various versions of DDMS.


	Back to Top

	Back to Downloads



<%@ include file="../shared/footer.jspf" %>

DDMS 4.1	DDMS 5.0
The `ddms:resource` element is a "metacard". The metacard is a full-fledged, top-level element containing all of the details about a described asset.	The `ddms:resource` element is an "assertion" in the IC's Trusted Data Object (TDO). The assertion by itself is insufficient for describing an asset, and the entire TDO record is needed to fully understand what is being described.
A metacard has five core sets (Metacard Info, Security, Resource, Summary Content, and Format) and an Extensible Layer.	An assertion has four core sets (Metacard Info, Resource, Summary Content, and Format) and no Extensible Layer. Security information has moved to the Enterprise Data Header (EDH) of the TDO. Extensions would be modeled as standalone assertions in the TDO, separate from the DDMS discovery assertion.
Cardinality of DDMS components is enforced in the XML schema.	Cardinality of DDMS components have been removed from the XML schema, to allow the schema to be used in alternate contexts. The specification still identifies some components as Mandatory for discovery.
Some Mandatory string components were allowed to have a nonsensical value of an "empty string".	DDMS now requires all Mandatory string components to have a minimum length of 1.
A GML profile and a custom `ddms:postalAddress` defintion are used for geolocations.	Geolocations are handled with the Time-Space-Position Information specification. `ddms:boundingBox`, `ddms:verticalExtent`, `gml:Point`, and `gml:Polygon` are replaced by comparable TSPI shapes.