[OAI-implementers] Branding

[Jeffrey A. Young]

> While I understand Jeff's concern about running XSLT processes on one's
> server, I don't see any real difference between a service provider doing
> that (perhaps in a well-controlled sandbox) or asking a downstream user to
> do it in their browser.

Unless someone knows of an existing XSLT processor that will timeout in this
situation, I can't imagine how to set up such a sandbox on my machine. This
situation on a server is much more critical than in a browser because it is
much more inconvenient to restart my server when it hangs in the middle of
the night than it is to kill a browser that is hung while I'm sitting in
front of it.

The major advantage to my model is that the risk is virtually eliminated
since no one in the XSLTProc network would dare catalog a problematic
stylesheet. If no one is willing to run it, I will simply ignore it and
apply a default stylesheet instead.

Jeff

> One might even argue that service provider is
> likely better equipped to control the dangers than a downstream user?
> 
> The branding spec says that "the style sheet must be able to render the
> metadata part of a GetRecord response" which is rather vague (for which
> I'm partly to blame). Should this say instead that "the style sheet must
> be able to render the <metadata> part of a <record> response" meaning that
> one could give it a record from a GetRecord or a record from a ListRecords
> response? The latter sounds more useful to me.
> 
> XHTML:
> 
> This seems the obvious default at present. However, XSLT1.0 doesn't have
> an XHTML output method (XSLT2.0 does but I hear tools for that aren't
> ready for prime-time yet, and the spec is just a Working Draft). With XSLT
> 1.0 I think that means one should probably use the 'xml' output method to
> avoid problems with possible collapsing of empty elements to ill-formed
> xml (e.g. <p/> -> <p>, see:
> http://www.w3.org/TR/xslt#section-HTML-Output-Method)
> 
> I agree with Hussein that it would be sensible to add an outputMimeType
> attribute to the <metadataRendering> element. Can anyone see a reason not
> to do this? (I should also fix the mimeType type in the schema which
> has a pattern that is too restrictive to permit all mime types).
> 
> 
> Incidentally, I added a metadataRendering declaration to
> http://arXiv.org/oai2 so I suppose there are now 5 repositories that do
> it.
> 
> Cheers,
> Simeon
> 
> 
> 
> 
> On Sat, 2 Oct 2004, Jeffrey A. Young wrote:
> > 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.
> >
> > Jeff
> >
> > > -----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 :)
> > >
> > > ttfn,
> > > ----hussein
> > >
> > >
> > >
> > > Young,Jeff wrote:
> > > > I have an immediate need for a best-practices description for
> creating
> > > XSLT
> > > > stylesheets for use with the description/branding/metadataRendering
> > > element
> > > > in an OAI Identify response
> > > > (http://www.openarchives.org/OAI/2.0/guidelines-branding.htm).
> > > >
> > > > The only guidance this specification gives regarding the stylesheet
> > > itself
> > > > is "the style sheet must be able to render the metadata part of a
> > > GetRecord
> > > > response for the specific metadata format". Unfortunately, it
> doesn't
> > > say
> > > > 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
> > > on
> > > > the result being assigned to a particular namespace? There are
> limits to
> > > how
> > > > many variants I should have to attempt in order to parse the result
> and
> > > use
> > > > it.
> > > >
> > > > There are only 4 repositories registered at UIUC that currently use
> this
> > > the
> > > > metadataRendering element, two of which are mine
> > > >
> > >
> (http://gita.grainger.uiuc.edu/registry/ListReposWithDesc.asp?desc=brandin
> > > g)
> > > > . I am on the verge, however, of creating a system that depends on
> them,
> > > as
> > > > 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:
> > > http://openarchives.org/mailman/listinfo/oai-implementers
> >
> >
> >
> > _______________________________________________
> > OAI-implementers mailing list
> > List information, archives, preferences and to unsubscribe:
> > http://openarchives.org/mailman/listinfo/oai-implementers
> >
> 
> _______________________________________________
> OAI-implementers mailing list
> List information, archives, preferences and to unsubscribe:
> http://openarchives.org/mailman/listinfo/oai-implementers