[auscope-geosciml] RE : RE : [Auscope-geosciml] GeoSciML version 3.0.0 [SEC=UNCLASSIFIED]
Eric.Boisvert at RNCan-NRCan.gc.ca
Sat Aug 7 11:45:39 EDT 2010
cocoon can handle Accept because it can read the header info, but it does not have a specific "accept header" logic component. The "redirector" is not in cocoon, only the service that decides where to redirect is in cocoon. I created a generic (non-cocoon) servlet that can run in any servlet container (in theory, just tried Tomcat) because
a) cocoon does not have a redirect component that issues 303 (just 302 and 301).
b) to not impose cocoon on anyone who wants to use it
the servlet component talks to an "redirection" service (which in our case is cocoon because I wanted to reuse some work we made on resolver). This redirection service (see ppt attached) just returns to the servlet a small XML redirection instruction, which is essentially a status code (it's also possible to tell the redirector to send a 404) and a list of URI and mime-types. Depending of the accept header, the redirector will chose a URI (or send a 307 - unsupported format if none matches) and respond to the caller.
This redirection service can be implemented on any plateform (PHP, ASP, another servlet, PERL, name it) that can generate the small XML snippet, we just used cocoon because we are cocoon junkies (and cocoon rocks.. admit it).
De: Stephen M Richard [mailto:steve.richard at azgs.az.gov]
Date: sam. 2010-08-07 11:00
À: Boisvert, Eric
Cc: auscope-geosciml at lists.arcs.org.au
Objet : Re: RE : [Auscope-geosciml] GeoSciML version 3.0.0 [SEC=UNCLASSIFIED]
Eric--can your Cocoon handler be made to honor http Accept headers?
Interesting discussion of http Accept header usage by web browsers:
On 8/6/2010 3:14 PM, Boisvert, Eric wrote:
> The format depends of content negociation (throught http Accept) -- as specified by Alistair/Simon. If you are using a browser, it will be HTML, if you are using some other clients that uses text/xml in the accept header, it will be xml.
> De: Stephen M Richard [mailto:steve.richard at azgs.az.gov]
> Date: ven. 2010-08-06 15:07
> À: Boisvert, Eric
> Cc: auscope-geosciml at lists.arcs.org.au
> Objet : Re: [Auscope-geosciml] GeoSciML version 3.0.0 [SEC=UNCLASSIFIED]
> Thanks a million Eric--this is great! I was trying to figure out how
> I was going to do this--putting xslt link in xml header in rdf-xml was
> what I was thinking.
> In terms of URI behavior, the question is what is the canonical form for
> the conceptScheme. In this configuration, dereferencing the URI returns
> html, but for an RDF environment, dereferencing should probably return
> the rdf. Can this be rigged to put '.html' at the end to return the
> html representation of the vocabulary? The http URI returns the
> canonical form (rdf) with no file extension, and html if the http URI
> has '.html' at the end? This could allow for other representation
> formats as well. (oops, opening the URI can of worms again...)
> On 8/6/2010 10:17 AM, Boisvert, Eric wrote:
>> Ahh.. I found the other XSLT..
>> Try again.. Much better indeed.
>> -----Message d'origine-----
>> De : Stephen M Richard [mailto:steve.richard at azgs.az.gov]
>> Envoyé : 6 août 2010 12:53
>> À : Boisvert, Eric
>> Objet : Re: [Auscope-geosciml] GeoSciML version 3.0.0 [SEC=UNCLASSIFIED]
>> Cool! so if the pattern could be set up to catch resolve/classifierScheme/CGI/*, then parse the vocab name and version from the last two segments of the URL, you could change the map:generate source to constuct the /vocabName.rdf string, so it would work for any vocabulary.
>> Is that possible?
>> Also interesting that the table formatting is returned different from what I get out of the xslt--the colors and fonts disappear...
>> On 8/6/2010 6:09 AM, Boisvert, Eric wrote:
>>> Bwa ah ah.. The power of Cocoon...
>>> Just created a pipeline in cocoon that reuses your SKOS and xslt
>>> straight from the subversion
>>> <map:match pattern="resolve/classifierScheme/CGI/ValueQualifier/200811.html">
>>> <map:generate src="https://www.seegrid.csiro.au/subversion/CGI_CDTGVocabulary/tags/SKOSVocabularies/ValueQualifier200811.rdf"/>
>>> <map:transform src="https://www.seegrid.csiro.au/subversion/CGI_CDTGVocabulary/trunk/xslt_files/DisplaySKOS_HTML.xslt"/>
>>> <map:serialize type="xml"/>
>>> And I have a resolvable URI reference to the vocab.
>>> -----Message d'origine-----
>>> De : auscope-geosciml-bounces at lists.arcs.org.au
>>> [mailto:auscope-geosciml-bounces at lists.arcs.org.au] De la part de
>>> Stephen M Richard Envoyé : 29 juillet 2010 16:22 À :
>>> auscope-geosciml at lists.arcs.org.au
>>> Objet : Re: [Auscope-geosciml] GeoSciML version 3.0.0
>>> value qualifier vocabulary is at
>>> xslt at
>>> files/DisplaySKOS_HTML.xslt will turn it into something more legible.
>>> (one of these days I'll figure out how to point the rdf-xml file at
>>> the xslt so it looks pretty when you open it in a browser...)
>>> Stephen M. Richard
>>> Arizona Geological Survey
>>> 416 W. Congress St., #100
>>> Tucson, Arizona, 85701
>>> phone: (520) 770-3500. FAX: (520) 770-3505
>>> email: steve.richard at azgs.az.gov
>>> On 7/29/2010 8:14 AM, Sen, Marcus A wrote:
>>>> What is the content model of gsmlcore:MappedFeature/gsmlcore:positionalAccuracy ? Schema doesn't seem to define anything.
>>>> In the cgu:CGI_Term element there is a mandatory qualifier property of gml:ReferenceType. The description says it has qualifying terms like sometimes, always etc. Are there some standard URIs for these qualifiers?
>>> Auscope-geosciml mailing list
>>> Auscope-geosciml at lists.arcs.org.au
>> Stephen M. Richard
>> Arizona Geological Survey
>> 416 W. Congress St., #100
>> Tucson, Arizona, 85701
>> phone: (520) 770-3500. FAX: (520) 770-3505
>> email: steve.richard at azgs.az.gov
> Stephen M. Richard
> Arizona Geological Survey
> 416 W. Congress St., #100
> Tucson, Arizona, 85701
> phone: (520) 770-3500. FAX: (520) 770-3505
> email: steve.richard at azgs.az.gov
Stephen M. Richard
Arizona Geological Survey
416 W. Congress St., #100
Tucson, Arizona, 85701
phone: (520) 770-3500. FAX: (520) 770-3505
email: steve.richard at azgs.az.gov
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 57856 bytes
More information about the GeoSciML