[GeoNetwork-devel] 'xlink:type' attribute in template document

Simon_Green · June 5, 2008, 5:57am

Hi Simon P,

We have a question about the xlink:type attribute applicable to several elements in the Geonetwork template document you provided us.

Using the example snippet below

<gmd:MD_Metadata
  ...
  <gmd:contact>
   <gmd:CI_ResponsibleParty>
    <gmd:contactInfo>
     <gmd:CI_Contact>
      <gmd:phone>
       ...
       <geonet:attribute xmlns:geonet="http://www.fao.org/geonetwork"
         name="type" add="true">
       <geonet:default value="simple" />
      </geonet:attribute>

Is the 'name' attribute of the 'geonet:attribute' element an xlink:type as described on http://www.w3.org/TR/xlink/#N1238 ?
If it is, am I correct in assuming that the only allowable value is 'simple'? Or are the other xlink:types allowable?

Have you had a chance to implement the modifications to GeoNetwork to provide us with the the Code Lists for our interface?

Kind regards

Simon G

--

--
Simon Green
  Email: simon.green@anonymised.com
  Mobile: 0408 554 536
Web:
  http://www.lisasoft.com
Offices:
  Sydney, NSW:
   Suite 112, Jones Bay Wharf, 19-21 Pirrama Rd, Pyrmont NSW 2009
   Phone: (02) 8570 5050
   Fax: (02) 8570 5099
  Melbourne, VIC:
   Lvl 9, 601 Bourke St, Melbourne VIC 3000
   Phone: (03) 8680 3250
   Fax: (03) 8680 3299
  Adelaide, SA
   Lvl 1, 30 Currie St, Adelaide SA 5000
   Phone: (08) 88425 8050
   Fax: (08) 88425 8099
Other A2End Companies:
  http://www.terrapages.com
  http://www.ardec.com.au

sppigot · June 8, 2008, 6:44pm

Simon Green wrote:

Have you had a chance to implement the modifications to GeoNetwork to provide us with the the Code Lists for our interface?

Hi Simon,

It is implemented and ready to test on http://bluenettest.its.utas.edu.au

Note: the name of the service has changed from xml.metadata.get to xml.metadocument.get and the only parameter required is the uuid - everything else is the same.

Codelists and help are included in the document returned under geonet:codelists and geonet:help

Cheers,
Simon

PS: BlueNet MEST with these services in it will be into the sandbox soon....

Roald_de_Wit3 · June 8, 2008, 11:56pm

Hi Simon Pigot,

Simon Pigot wrote:

It is implemented and ready to test on http://bluenettest.its.utas.edu.au

Note: the name of the service has changed from xml.metadata.get to
xml.metadocument.get and the only parameter required is the uuid -
everything else is the same.

Codelists and help are included in the document returned under
geonet:codelists and geonet:help

Thanks for this! I've just had a look the output of the template service and have a few ideas in relation to that:

- is the template the right place for outputting the geonet:codelists and geonet:help? Maybe in a future version we could add them as a separate service (or one service that can output different kinds of content). We'd need a separate code list and help instance anyway when build build up a form from scratch.

- I think the snippet service should hold references to the code lists (just as the template already has). Imagine we have an incomplete template or we build up our form from a blank document (say snippet parent=/ & child=gmd:MD_Metadata). Then we need to know that the following node for example is linked to a code list:

<geonet:child name="characterSet" prefix="gmd">

Currently the snippet service outputs the following (I've taken out the name spaces for readability):

    <gmd:characterSet>
      <gmd:MD_CharacterSetCode codeList="" codeListValue="">
        <geonet:element ref="2" />
        <geonet:attribute name="codeList" />
        <geonet:attribute name="codeListValue" />
        <geonet:attribute name="codeSpace" add="true" />
      </gmd:MD_CharacterSetCode>
      <geonet:element ref="1" />
      <geonet:attribute name="gco:nilReason" add="true" />
    </gmd:characterSet>

We're nearly there: we only need to fill in the codeList and codeListValue attributes in the service.

Something else, but related: in the template I notice that the reference to the code list is something like this:

codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelist.xml#MD_CharacterSetCode" codeListValue="utf8"

The file gmxCodelist.xml doesn't exist (it is in fact gmxCodelists.xml), so I assume that GN takes a local code lists file and 'manually' creates the URL. I've got 2 possible suggestions:
1) Fix the URL so we can have our XSLT or XForms request the the code lists directly from the authoritive site (pro: always up2date, con: network latency and risk of failure when site is down or another name change)
or
2) Change the value of attribute codeList to: codeList="MD_CharacterSetCode" in the template and snippet service. This makes it much easier for us to find the correct codelist values based on the attributes (codeList and codeListValue) given (using XSLT 1.0).

I'd prefer suggestion 2 myself but. How do you feel about this? Would this be easy to implement? Or, now I come to think of it: is the id of the entry in the code list *always* the name of the node: gmd:MD_CharacterSetCode in this case? If so, then it is much easier and no further work needs to be done on your side.

Thanks again for all the work you're doing on this.

Cheers, Roald

Roald_de_Wit3 · June 9, 2008, 1:26am

Hi Simon,

Looking further into the code list matter I noticed that the current web interface for editing GN documents uses gmxCodelists.xml for creating a selection list for languages (and probably a few other values as well).
Do you advise us to do that too? It is not hard to implement this in an XForm, but requires us to create exceptions like:

"if node is characterstring, create text input field except if field
name is gmd:language"

If we use gmxCodelists.xml we won't need the geonet:codelist bit either (since gmxCodelists.xml contains everything we need). Is that correct?

Cheers,

Roald

sppigot · June 9, 2008, 3:46am

Roald de Wit wrote:

Hi Simon Pigot,

Simon Pigot wrote:

It is implemented and ready to test on http://bluenettest.its.utas.edu.au

Note: the name of the service has changed from xml.metadata.get to
xml.metadocument.get and the only parameter required is the uuid -
everything else is the same.

Codelists and help are included in the document returned under
geonet:codelists and geonet:help

Thanks for this! I've just had a look the output of the template service and have a few ideas in relation to that:

- is the template the right place for outputting the geonet:codelists and geonet:help? Maybe in a future version we could add them as a separate service (or one service that can output different kinds of content). We'd need a separate code list and help instance anyway when build build up a form from scratch.

Yep - its already there - xml.schema.info - its used by the tooltips - eg. xml.schema.info?&element=gmd:MD_DataIdentification should return help where as xml.schema.info?codelist=whatever should return the codelist. Have a look in the tooltip js for examples of its use if you want to use it.

The codelists in the metadocument (to avoid confusion with geonetwork's idea of template) are complete - all help and codelists are there - that way you have the option of going to the server and grabbing the metadocument and all codelists and help for the schema you're working on just once as opposed to lots of small Ajax requests via xml.schema.info.

- I think the snippet service should hold references to the code lists (just as the template already has). Imagine we have an incomplete template or we build up our form from a blank document (say snippet parent=/ & child=gmd:MD_Metadata). Then we need to know that the following node for example is linked to a code list:

   <geonet:child name="characterSet" prefix="gmd">

Currently the snippet service outputs the following (I've taken out the name spaces for readability):

   <gmd:characterSet>
     <gmd:MD_CharacterSetCode codeList="" codeListValue="">
       <geonet:element ref="2" />
       <geonet:attribute name="codeList" />
       <geonet:attribute name="codeListValue" />
       <geonet:attribute name="codeSpace" add="true" />
     </gmd:MD_CharacterSetCode>
     <geonet:element ref="1" />
     <geonet:attribute name="gco:nilReason" add="true" />
   </gmd:characterSet>

    We're nearly there: we only need to fill in the codeList and codeListValue attributes in the service.

Can be done but I'd always thought you'd have a base document (known as a template in geonetwork) which has the basic fields relevant to the user already expanded and some with existing content - you get this document using xml.metadocument.get and then add snippets as editing continues.

Something else, but related: in the template I notice that the reference to the code list is something like this:

codeList="http://www.isotc211.org/2005/resources/Codelist/gmxCodelist.xml#MD_CharacterSetCode" codeListValue="utf8"

The file gmxCodelist.xml doesn't exist (it is in fact gmxCodelists.xml), so I assume that GN takes a local code lists file and 'manually' creates the URL. I've got 2 possible suggestions:
1) Fix the URL so we can have our XSLT or XForms request the the code lists directly from the authoritive site (pro: always up2date, con: network latency and risk of failure when site is down or another name change)
or
2) Change the value of attribute codeList to: codeList="MD_CharacterSetCode" in the template and snippet service. This makes it much easier for us to find the correct codelist values based on the attributes (codeList and codeListValue) given (using XSLT 1.0).

I'd prefer suggestion 2 myself but. How do you feel about this? Would this be easy to implement? Or, now I come to think of it: is the id of the entry in the code list *always* the name of the node: gmd:MD_CharacterSetCode in this case? If so, then it is much easier and no further work needs to be done on your side.

Thanks again for all the work you're doing on this.

I'll take suggestion 1 - that attribute should refer to the authoritative source - at present geonetwork uses its own local copies (which are manually proxied at present) - and thanks for picking that up I'll fix it in the update of fixed info for the metadata in the MEST.

Cheers,
Simon

sppigot · June 9, 2008, 4:05am

Roald de Wit wrote:

Hi Simon,

Looking further into the code list matter I noticed that the current web interface for editing GN documents uses gmxCodelists.xml for creating a selection list for languages (and probably a few other values as well).
Do you advise us to do that too? It is not hard to implement this in an XForm, but requires us to create exceptions like:

"if node is characterstring, create text input field except if field
name is gmd:language"

If we use gmxCodelists.xml we won't need the geonet:codelist bit either (since gmxCodelists.xml contains everything we need). Is that correct?

Cheers,

Roald

Language support is available through the geonet:codelist and geonet:help - at the moment it is using english only - language support in GN is probably one of the reasons why the codelists are proxied manually and rebuilt into simpler xml structures. I'm not aware of better language support than what GN provides for these codelists (but someone else may know better!) so if the interface we're building is to be used elsewhere then we should use the language support provided by GN - to me that means geonet:codelists and geonet:help.

Do you want the snippet service to build small lists of labels and codelists according to content and attach them as geonet: elements? Or are you going to take the xml.schema.info path and request them from geonetwork as required? Probably should do both.

Anyone else care to comment?

Cheers,
Simon

ticheler · June 11, 2008, 6:04am

Hi Simon and Roald,
I was about to react on the previous email on exactly the below Happy you also noticed this. As long as there's no authoritative source that provides acknowledged translations, I think we better proxy them. It is up to us to ensure we keep them aligned with the official source. Also for people that run the software offline proxying is vital. So unless there's an automatic fallback, I think we should always proxy those kind of things.
Cheers,
Jeroen

On Jun 9, 2008, at 6:05 AM, Simon Pigot wrote:

Language support is available through the geonet:codelist and
geonet:help - at the moment it is using english only - language support
in GN is probably one of the reasons why the codelists are proxied
manually and rebuilt into simpler xml structures. I'm not aware of
better language support than what GN provides for these codelists (but
someone else may know better!) so if the interface we're building is to
be used elsewhere then we should use the language support provided by GN
- to me that means geonet:codelists and geonet:help.