Here are my two cents worth:
If I get an XML metadata document from your CSW I will want to, of course,
validate that document. If there are xlinks in that document then my
validator should be able to resolve those xlink references. To do this all
those references must be full not relative.
At the same time if I know of an XML document, such as the ISO 19139
codeLists, I don't want to use up bandwidth to access this document each time
an XML document refers to it. I should be able to refer to a local copy of
that XML document if I believe it doesn't change that often. This will also
overcome problems if the web site that delivers that XML document is
unavailable.
Most DSDLs can be referred to in an OASIS Catalog file so that those DSDLs
can refer to local copies even though the official URIs are provided in the
XML document instance. For example, my XML document instances refer to ISO
19139 XSDs, however, when I validate those XML documents the OASIS Catalog
file refers to local copies of those XSDs during the validation process.
We need something like this process for Xlink. That is, local copies of the
official xlink values are referred to when the Xlink components are being
resolved in the individual XML metadata document instances.
Therefore, the full paths to the official Xlink XML documents should be used
but if we can find some way of referring to local copies of those documents
via something like OASIS Catalog files, then we should use those. Otherwise
validation of the XML metadata document instances will fail when being
validated on a different system to their originator system.
Thanks.
John
-----Original Message-----
From: geonetwork-devel-bounces@lists.sourceforge.net
[mailto:geonetwork-devel-bounces@lists.sourceforge.net] On
Behalf Of Jeroen Ticheler
Sent: Wednesday, 11 June 2008 4:04 PM
To: Simon.Pigot@anonymised.com
Cc: Roald de Wit; geonetwork-devel@lists.sourceforge.net; Simon Green
Subject: Re: [GeoNetwork-devel] 'xlink:type' attribute in
template documentHi 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,
JeroenOn 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.--------------------------------------------------------------
-----------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
GeoNetwork-devel mailing list
GeoNetwork-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geonetwork-devel
GeoNetwork OpenSource is maintained at
http://sourceforge.net/projects/geonetwork
