[fdo-internals] Re-Openeing FDO RFC 10

[Greg Boone]

Hi All,

It looks as if we will have to revisit RFC 10: 'Modify WMS override API
to support additional parameters and bit depth variations'

http://trac.osgeo.org/fdo/wiki/FDORfc10

The RFC as defined and implemented is not forwards compatible with
Autodesk Map 3D 2008. Testing using that platform resulted in an
unexpected exception and the failure of the application. 

Here is the WMS Configuration File content that identifies the content
change that causes the exception:

Map 3D 2008	Map 3D 2009 (Development Version)	
<RasterDefinition name="Image">
  <Format>PNG</Format>
...
 </RasterDefinition>	<RasterDefinition name="Image">
  <Format>image/png; mode=24bit</Format>
...
 </RasterDefinition>	
 
Map 3D 2008 is unable to decipher the appended text: 'mode=24bit', or
any other variation of the WMS format type.

Here is the proposed solution I have in mind to resolve the issue.

Revert the content change to <Format> element made in 3.3 and continue
to write the value of the <Format> element as was previously done in
3.2.2. This would allow continued compatibility with applications
written for 3.2.2. At the same time the FDO 3.3 WMS provider
configuration file would be modified to contain a new <FormatType>
element that would only be evaluated by the 3.3 version of the WMS
provider and subsequent releases. FDO 3.3 would look for <FormatType>
first and if not found evaluate <Format>. FDO 3.2.2 would continue to
evaluate <Format>  and ignore <FormatType>. There would some duplication
of information, but applications written on both versions of the WMS
Provider should continue to work as designed. The <Format> would be
deemed deprecated and removed once forward compatibility support is no
longer required.

The resulting 3.3 WMS configuration xml document would take the form
of...

		<RasterDefinition name="Image">
		  <Format>PNG</Format> // Deprecated element. This one
is consistent with FDO 3.2.2
	
<FormatType>image/png;PhotometricInterpretation=PaletteColor</FormatType
>
		...
		</RasterDefinition>

For the 3.2.2 FDO WMS configuration API....

		Calls to 

		void
FdoWmsOvRasterDefinition::SetFormatType(FdoWmsOvFormatType value);
		
		would continue to result in the generation of XML
content that contained only the FORMAT element as follows 
		
				<RasterDefinition name="Image">
				  <Format>PNG</Format>
				...
				</RasterDefinition>
		
		Calls to 
		
		FdoWmsOvFormatType
FdoWmsOvRasterDefinition::GetFormatType(void) const;
		
		would continue to result in the return of the expected
FdoWmsOvFormatType enumeration type 


For the 3.3 FDO WMS configuration API, 

		Calls to 

				void SetImageFormat(FdoString* value);
		
		would result in the generation of XML content that
contained both <Format> and <FormatType>

				<RasterDefinition name="Image">
				  <Format>PNG</Format>
	
<FormatType>image/png;PhotometricInterpretation=PaletteColor</Format>
				...
				</RasterDefinition>
				
		where the content of <FormatType> is the content passed
through the call to SetImageFormat() and the content of <Format> is
interpreted and set form the allowed values of <FormatType>, with a
default value of PNG being used no valid interpretation can be made.
		
		Calls to 
		
		FdoString* GetImageFormat(void) const;
		
		would result in the return of the expected string set
through the call to SetImageFormat() and/or the value contained in the
<FormatType> element. The content in <Format> would not be returned or
evaluated.

NOTE: There was some consideration to creating a separate XML element to
contain the additional type information that would work in conjunction
with <Format>, thus preventing the need to deprecate it. This idea was
considered but rejected due to the belief that it would be improper to
separate an arbitrary server defined string value into 2 FDO XML string
configuration elements and expect the application or provider to be able
to determine how the strings should be concatenated to form a valid
request to the WMS server. There is no set standard on how the server
would return the format type strings as XML in the WMS server
capabilities response document, so it is best to maintain the string as
returned the server as a single entity.

Thoughts/Ideas/Feedback?

Regards,

Greg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/fdo-internals/attachments/20071023/a2ebcbe5/attachment-0001.html