[Auscope-geosciml] RE : CGI Value abomination

Boisvert, Eric Eric.Boisvert at RNCan-NRCan.gc.ca
Tue Sep 1 05:25:20 EDT 2009


should we bring the swe encoding back to the table. it has been rejected in Tucson on the basis that we were not ready to deal with it.  Or is swe just CGI_Value in another dress ?
 
Eric

________________________________

De: auscope-geosciml-bounces at lists.arcs.org.au de la part de Laxton, John L
Date: mar. 2009-09-01 05:08
À: auscope-geosciml at lists.arcs.org.au
Objet : Re: [Auscope-geosciml] CGI Value abomination



I think we have definitely over-used CGI_Value - as I recall it was put in almost ubiquitously on the basis that with experience of the use of GeoSciML we would have a better idea what type of data was actually being used for particular properties. We now have that experience for many, but by no means all, of the properties so we should definitely be able to reduce the use of CGI_Value.

 

That said a couple of points need to be remembered:

 

1. As well as allowing us to be imprecise about the basic type of a property CGI_Value allows us to add a qualifier to the value. I think given the nature of much geoscience data there is requirement for this for many properties, even where we can now allocate a precise data type - this doesn't just apply to field data.

 

2. There are definitely some properties (eventAge springs to mind) where the ability to specify the property in a range of different ways is essential.  

 

We should therefore be able to reduce the use of CGI_Value, but not eliminate it.

 

John

 

From: auscope-geosciml-bounces at lists.arcs.org.au [mailto:auscope-geosciml-bounces at lists.arcs.org.au] On Behalf Of Simon Cox
Sent: 01 September 2009 08:10
To: Oliver.Raymond at ga.gov.au
Cc: auscope-geosciml at lists.arcs.org.au
Subject: [Auscope-geosciml] CGI Value abomination

 

Ollie, others:

 

I have been grumbling about this for a while, and hope that it can be addressed in the upcoming meeting in Quebec. 

 

 

Way too many of the class attributes in GeoSciML use CGI_Value and its variants. 

 

I am fully aware of the history of when CGI_Value it was created (Ottawa, 2005) and its value (it allowed us to move forward on the bigger issues). 

It also allowed a lazy UML design process, where for most atttributes the type was set following a logic of just 'we can't really think about this now but it'll be some kind of word/number'. 

 

Now I think it is time to set it aside and move on. 

 

My fundamental objections to the almost ubiquitous use of CGI_Value are

(i) it is hard to implement - it relies on XML Schema substitution groups

(ii) it is not compatible with any other domain schema

(iii) it allows data providers to be 'lazy' and create instances that are not interoperable on arrival

(iv) it forces decisions required for data-fusion over to the client - this is fundamentally what a standard encoding is supposed to avoid!

(v) it privileges a marginal GeoSciML use-case (transmission of field data) at the expense of the dominant use-case (exchange of quality-controlled archival data). 

 

Most of the time, the client will refer to 'standard definitions' provided in the GeoSciML concept schemes to translate the values provided into standard forms anyway, so why not get the provider to do that rather than the client

 

It is the job of the GeoSciML design task group to actually make some choices, fix the type of the basic class attributes, and then require that service providers conform - make them make the choice about the 'best' value for an attribute, don't shirk the job and push it back to the client. 

 

Almost all CGI_Value should be replaced by 

(a) ScopedName

(b) Measure

with just a few being 

(c) Range (new type)

 

Simon

 

 

--------------------------------------------------------
Simon Cox

European Commission, Joint Research Centre 
Institute for Environment and Sustainability 
Spatial Data Infrastructures Unit, TP 262 
Via E. Fermi, 2749, I-21027 Ispra (VA), Italy 
Tel: +39 0332 78 3652 
Fax: +39 0332 78 6325 
mailto:simon.cox at jrc.ec.europa.eu <mailto:simon.cox at jrc.ec.europa.eu>  
http://ies.jrc.ec.europa.eu/simon-cox <http://ies.jrc.ec.europa.eu/simon-cox>  

SDI Unit: http://sdi.jrc.ec.europa.eu/ <http://sdi.jrc.ec.europa.eu/>  
IES Institute: http://ies.jrc.ec.europa.eu/ <http://ies.jrc.ec.europa.eu/>  
JRC: http://www.jrc.ec.europa.eu/ <http://www.jrc.ec.europa.eu/> 

--------------------------------------------------------

 


-- 
This message (and any attachments) is for the recipient only. NERC 
is subject to the Freedom of Information Act 2000 and the contents 
of this email and any reply you make may be disclosed by NERC unless 
it is exempt from release under the Act. Any material supplied to 
NERC may be stored in an electronic records management system. 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/ms-tnef
Size: 9774 bytes
Desc: not available
URL: <http://lists.opengeospatial.org/pipermail/geosciml/attachments/20090901/2ae7a952/attachment.bin>


More information about the GeoSciML mailing list