Roald de Wit wrote:
> Hi Simon,
>
> For our metadata editor project you've setup an initial version of a
> 'snippet service'. We will most likely use and XForms solution that will
> dynamically request these snippets.
>
> Some background info for the GN devel list subscribers:
>
> ------------
> This snippet service allows for requesting snippets of GN's internal
> template representation for building a metadata edit form. This can be
> particularly useful when building an editor that requests bits and
> pieces for building its form only when it needs to.
>
> The idea behind this all is: when creating a form, finding out what
> attributes and child nodes are required/allowed etc using XSD and
> Schematron is difficult to do (especially in the case of ISO-19139 with
> many XSDs and rules). Since GN already has tackled this problem, why not
> use what GN knows?
>
> Please don't hesitate to ask if you're interested and want to know more
> about it.
> ------------
>
> Simon, we've got a few questions about the current implementation of the
> snippet service:
>
> - You've set up the initial service on a BlueNet test instance. Are you
> OK with us advertising the URL on this list?
Probably not- we should get the code into the sandbox asap - so anyone can set up their own.
> - What version/branch of GN would you advise us to use in our newly
> created sandbox? The vanilla GN trunk/2.2 or the BlueNet one?
Ultimately, you'll need the ANZLIC profile if you're going to put records back into GeoNetwork for validation but for the moment it may be easier to use vanilla 2.2 until we clear up what bits of BlueNet go into the trunk. I'll check the changes in to support the snippet service etc once you've put 2.2 in the sandbox.
> - Would it be wise to have the snippet service code in that sandbox?
> - As you explained to us, the service doesn't include CodeLists yet. How
> much work would it be to include these too and would that create a
> different snippet for, say 'gmd:language' (which is a text field now)?
I think the workflow for the external editor we've defined so far is that you start off by using an initial get service to get the basic document/record you're interested in. eg.
This would get an initial metadocument (=xml document + XSD info stored in elements with a geonet: namespace) that would be used to build the initial form. Then as editing continues and the user takes an action that requires adding an element to the interface, you would use the snippet service with the name of the element you want to add and the schema (taken from the geonet:info element in the metadocument). Snippet service doesn't care about your document - it just builds a metadocument containing the element you want - its up to your editor to add the element it gets back from the snippet service into your document.
I think we should describe the metadocument elements on the UI wiki Simon Green has set up.
Now re: codelists, GeoNetwork includes these codelists as part of the guiservices (they come from files such as web/geonetwork/xml/schemas/iso19139/loc/en/codelists.xml) - I think its probably best to keep this strategy by including the relevant codelists with the metadocument from the get service above. Looks straightforward so I'll add them to it.
> - The current web user interface in GN for editing metadata has
> information about mandatory elements and human readable labels (and help
> info). That info does not appear in the snippets. How can we retrieve
> that info for our editor?
Mandatory elements can be mandatory in one use and optional/conditional in another (eg. gmd:contact in gmd:MD_Metadata and gmd:MaintenanceInformation) - I think a reasonably reliable way of doing mandatory elements is to look in the metadocument to see whether the element can be deleted or not - in the metadocument, there are elements called geonet:element that have an attribute del="true" if they can be removed by the editor (ie. they are not mandatory) - this comes from minOccurs/maxOccurs in the XSD.
Re: labels and help - in the geonetwork editor the tooltip AJAX code is used to look up the help for an element using the xml.schema.info service - it get backs info from the help file for the schema (eg. web/geonetwork/xml/schemas/iso19139/loc/en/labels.xml) with the info you want.
> - We have been trying to 'manually' use the available XSL files that
> convert a GN 'internal representation' XML file into a the web HTML form
> that GN currently uses, but haven't succeeded. Can you give a hint what
> XSL files to use and in what order?
I'd start by looking at metadata-show.xsl or metadata-edit.xsl - the basic idea is that you apply the template with mode="elementEP" to the root element of the metadata. The focus then switches to the elementEP template(s) in metadata.xsl where the schema is divined from the geonet:info element (or failing that, the name of the root element) and a switch is made to the appropriate mode of templates relevant to that schema - in the case of iso19139, these templates are in metadata-iso19139.xsl - the schema templates eventually call back other templates from metadata.xsl to do the job of displaying the metadata or building the form for editing.
> - We need to be able to handle 'special cases', ie where the data
> maintainer's requirements are different from the standard. Your idea was
> to allow adding a custom XSD to GN for these purposes. How would this
> affect the snippet service?
Snippet service should work on whatever schema you specify - I'll need to look at the XSD you've provided to make sure its ok with GeoNetwork.
I hope those who wrote some of the services/functions I referred to above will correct anything thats not clear or needs more detail!
Cheers,
Simon