Jeffrey A. Young
jyoung1 at columbus.rr.com
Sat Oct 2 13:17:35 EDT 2004
I vote against fragments. The reason is a little involved.
The problem starts with the fact that I am not willing to run unknown
stylesheets on my machine. As mentioned at the bottom of section 5.4 of the
XSLT spec (http://www.w3.org/TR/xslt#section-Applying-Template-Rules), there
is a denial of service risk associated with running stylesheets.
The solution I've come up with is to create an XSLT processor web service
coupled with a catalog of stylesheets that the processor service is willing
to perform. This has been bundled into an open-source Java Servlet
distribution named XSLTProc so anyone can set it up to support stylesheets
they are interested in using. The parameters to this service are the same as
they would be calling the XSLT processor from the command line.
The catalog for this service will be OAI-harvestable which will allow me to
create a union catalog and couple that with another open-source web service
that accepts the same arguments XSLTProc does, except that instead of
performing the transform, it will perform an HTTP redirect to a willing
XSLTProc service instead.
This solution may be less efficient than running the stylesheet directly,
but it is the only way I can think of to manage the risk of running unknown
stylesheets. There are many other interesting and uses for this model,
though, that I won't go into now.
Getting back to the problem with fragments, a stylesheet that produces
fragments would be fine if I imported it locally into another stylesheet,
for example, but I think the XSLTProc service must be bound to produce
well-formed XML so that the client can manage the response using XML tools
rather than being forced to treat it as a string.
Sorry that this has led to such a tangent, but this is the problem and
solution I am facing.
> -----Original Message-----
> From: oai-implementers-bounces at openarchives.org [mailto:oai-implementers-
> bounces at openarchives.org] On Behalf Of Hussein Suleman
> Sent: Saturday, October 02, 2004 12:48 PM
> To: Young,Jeff
> Cc: oai-implementers at oaisrv.nsdl.cornell.edu
> Subject: Re: [OAI-implementers] Branding
> hi Jeff
> i would vote in favour of standalone XHTML 1.0.
> at first fragments sounded nicer (for integration), but then what if the
> rendering is PDF or Mobile-HTML or some such thing ... and then again
> XHTML is sooner or later going to be v2.0 anyway. with a complete
> document, we can at least make the assumption of a mime type and promote
> this to a problem the browser mediates.
> then maybe in a later "bugfix", Simeon (or whoever is the maintainer)
> can introduce a "target-mime-type" attribute or some such mechanism in
> the metadataRendering container.
> but is there a mime type for HTML fragments? if there is, then maybe the
> fragment is the way to go ... as long as down the road we can widen the
> scope without any changes. if there is no fragment mime type, maybe we
> can introduce one :)
> Young,Jeff wrote:
> > I have an immediate need for a best-practices description for creating
> > stylesheets for use with the description/branding/metadataRendering
> > in an OAI Identify response
> > (http://www.openarchives.org/OAI/2.0/guidelines-branding.htm).
> > The only guidance this specification gives regarding the stylesheet
> > is "the style sheet must be able to render the metadata part of a
> > response for the specific metadata format". Unfortunately, it doesn't
> > what the stylesheet should render it into. Should it be an HTML fragment
> > suitable for dropping into the body of an HTML document? Should it be a
> > stand-alone XHTML document ready to display in a browser? Can I depend
> > the result being assigned to a particular namespace? There are limits to
> > many variants I should have to attempt in order to parse the result and
> > it.
> > There are only 4 repositories registered at UIUC that currently use this
> > metadataRendering element, two of which are mine
> > . I am on the verge, however, of creating a system that depends on them,
> > well as updating many of my repositories to include them.
> > It would be nice to have this group's consensus before I commit to a
> > particular solution.
> > Jeff
> > _______________________________________________
> > OAI-implementers mailing list
> > List information, archives, preferences and to unsubscribe:
> > http://openarchives.org/mailman/listinfo/oai-implementers
> hussein suleman ~ hussein at cs.uct.ac.za ~ http://www.husseinsspace.com
> OAI-implementers mailing list
> List information, archives, preferences and to unsubscribe:
More information about the OAI-implementers