<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Hi NeXus Committee,<br>
<br>
Peterson, Peter F. wrote:
<blockquote
cite="midD47D8CA3F077394CA1B65096E5C701660149C319@ORNLEXCHANGE.ornl.gov"
type="cite">
<pre wrap="">One of the action items from the last meeting was converting the NeXus
homepage from html <a class="moz-txt-link-rfc2396E" href="http://www.nexus.anl.gov/"><http://www.nexus.anl.gov/></a> to wiki
<a class="moz-txt-link-rfc2396E" href="http://www.nexus.anl.gov/mediawiki/"><http://www.nexus.anl.gov/mediawiki/></a> (with a suggestion of exploring
plone as an alternative). I think that this will be easiest if it is
done as a coordinated group effort. Here is my first pass at the major
tasks to be done:
1. Index what pages are on old site and make sure that their content is
on the new site.
</pre>
</blockquote>
There are literally hundreds of web site mapping tools that will help,
such as:<br>
<br>
<a class="moz-txt-link-freetext" href="http://linkchecker.sourceforge.net/">http://linkchecker.sourceforge.net/</a><br>
<br>
The Google Sitemap offers itself as a standard "stocktaking map, and
there are many tools that can generate such:<br>
<br>
<a class="moz-txt-link-freetext" href="http://www.autositemap.com/">http://www.autositemap.com/</a><br>
<br>
<blockquote
cite="midD47D8CA3F077394CA1B65096E5C701660149C319@ORNLEXCHANGE.ornl.gov"
type="cite">
<pre wrap=""> 2. Update the base classes on the wiki that were modified by the
ratification of TOFRAW.
3. Update the definitions on the cvs server to match what is on the
wiki.
</pre>
</blockquote>
As I explain below in more detail I believe one can use XSL
transformation from the CVS (as the "canonical source" of NeXus XML
files)<br>
to the Wiki (as a "dumb" HTML target of dynamically transformed and
presented data structures) to avoid the need for this tedious type of
synchronisation.<br>
<br>
Wiki, being HTML, is simply not suited for defining data structures
(except as a very temporary sandbox).<br>
It is not so hard to edit a file directly in XML rather than fiddling
with HTML or tables in the Wiki !<br>
<blockquote
cite="midD47D8CA3F077394CA1B65096E5C701660149C319@ORNLEXCHANGE.ornl.gov"
type="cite">
<pre wrap=""> 4. Provide an easier means for synchronizing the definitions on the
wiki with those in cvs. (Darren Kelly had volunteered to help us with
this)
</pre>
</blockquote>
Not quite. I suggested that one use dynamic XSL transformation serving
of the XML
meta-DTDs and instrument definitions to web (HTML).<br>
<br>
Indeed I've been
preparing a demonstration of that (which is not yet www public). The
idea is to show how one can take the XML artefacts/output of the NIAC
(from CVS, wiki, or elsewhere) and
"value-add" with XSL transformations (or similarly by parsing NeXus XML
files with my XML2Java translator I used to create the
"NeXusBeans" I demonstrated in Java and UML). <br>
<br>
This will not be "yet another NeXus web site", it is a dynamic site
that is generated from specific XML artefacts of the official site or
CVS. (No feedback loops yet.)<br>
<br>
I volunteered to create XSL stylesheets that operate on the XML
meta-DTDs and instrument definitions and serves formatted tabular
representations as HTML, and that work is underway<br>
(I was already doing it on the plane on the way to NIAC2006 and
demonstrated it during my presentation).<br>
<br>
How one can combine that with your CVS (as a source of XML definitions)
and then with your Wiki (as target of the dynamic transformations to
HTML ) is not something I've thought through, although I can't imagine
it would be very difficult. I've not yet even accessed your CVS.<br>
<br>
In most modern web browsers XSL transformations are performed
"client-side" automatically if specified at the top of the XML file.
Like this:<br>
<blockquote>
<pre><?xml version="1.0" encoding="UTF-8"?></pre>
<pre><?xml-stylesheet version="1.0" type="text/xsl" href="nexus.xsl"?></pre>
<pre><!--</pre>
<pre>URL: <a class="moz-txt-link-freetext" href="http://www.nexus.anl.gov/classes/xml/NXgeometry.xml">http://www.nexus.anl.gov/classes/xml/NXgeometry.xml</a></pre>
<pre>Editor: NIAC</pre>
<pre>$Id: NXgeometry.xml,v 1.2 2005/07/19 04:10:26 rio Exp $
...
</pre>
<pre>-->
<NXgeometry name=""></pre>
<pre>...</pre>
<pre></NXgeometry>
</pre>
</blockquote>
So in principle, one could just include the correct headers in your XML
files, and voila ! Unfortunately, some browsers work with different
media-types for the stylesheet than others: "text/xml", "text/xsl",
"application/xsl". Therefore web developers using JavaServer Pages
perform the transformation "server-side" that the result is ensured for
all web browsers. Like this example using standard JSP taglibs:<br>
<blockquote>
<pre><!-- many xml pages served with same jsp and same style using query param --></pre>
<pre><c:set var="page" value="${param.page}"/></pre>
<pre><c:if test="${empty page}"></pre>
<pre><c:set var="page" value="index"/></pre>
<pre></c:if></pre>
<pre><c:import var="xml" url="/classes/${page}.xml"/></pre>
<pre><c:import var="xslt" url="/classes/classes.xsl"/></pre>
<pre><x:transform xslt="${xslt}" xml="${xml}"/></pre>
</blockquote>
Sorry I can't show that working live yet, I am organising permission
for public access to a JSP demo site for NeXus at ANSTO.<br>
<br>
[One can see how quickly that works by viewing my dynamically generated
IT education web site: <a class="moz-txt-link-freetext" href="http://www.webel.com.au">http://www.webel.com.au</a>.<br>
All of the content there is composed in XML, there is no HTML "content"
anywhere, it is just marked up in HTML on the fly.]<br>
<blockquote
cite="midD47D8CA3F077394CA1B65096E5C701660149C319@ORNLEXCHANGE.ornl.gov"
type="cite">
<pre wrap=""> 5. Set up redirection pages in place of the old sites.
</pre>
</blockquote>
You might recall that I mentioned a WWW Handle Service content referral
strategy for tracking resources.<br>
Instead of using a URL each document gets a URN that is used to track
the document through the handle service.<br>
Someone then manages the referral mappings so that users of the
original target never get lost.<br>
<br>
A good description of why one would want to do this and how it works
can be found here:<br>
<br>
<a class="moz-txt-link-freetext" href="http://www.handle.net/rfc/rfc3651.html">http://www.handle.net/rfc/rfc3651.html</a><br>
<br>
To make this work NIAC would apply to be a naming authority (a prefix
that defines a namespace for your documents).<br>
<br>
See also the excellent site:<br>
<br>
<a class="moz-txt-link-freetext" href="http://www.dtic.mil/dtic/handles/handles_faq.html">http://www.dtic.mil/dtic/handles/handles_faq.html</a><br>
<br>
<font face="Arial" size="-1"><b>How is a handle different from a URL? </b></font>
<p><font face="Arial" size="-1">The Uniform Resource Locator (URL)
identifies the place an object is located. A handle is a name used to
identify an object. A URL ties an Internet resource to its current
network location and to its local file path. The problem is that, by
definition, a location cannot serve as an identifier. When the resource
is moved, the connection is severed and the URL link is broken. URLs
must change when the object moves to another location. A useful analogy
might be to equate a URL with a physical address where a person
resides. If people are known solely by their address, when they move to
another location there is no way to find them. They may leave a
forwarding address, but eventually, forwarding addresses become
unmanageable. However, if they are known by their name, it is easier to
find them. The Handle System®, instead of identifying a file's
location, assigns an identifier and stores information that can be
updated to reflect its current location. No matter where the file is
moved, you can use the handle to get to the information; the handle
remains valid.</font></p>
<blockquote
cite="midD47D8CA3F077394CA1B65096E5C701660149C319@ORNLEXCHANGE.ornl.gov"
type="cite">
<pre wrap="">
Does this seem like the appropriate list?
</pre>
</blockquote>
Yes.<br>
<blockquote
cite="midD47D8CA3F077394CA1B65096E5C701660149C319@ORNLEXCHANGE.ornl.gov"
type="cite">
<pre wrap="">Who will coordinate the work?
</pre>
</blockquote>
You.<br>
<blockquote
cite="midD47D8CA3F077394CA1B65096E5C701660149C319@ORNLEXCHANGE.ornl.gov"
type="cite">
<pre wrap="">Who can volunteer to help with the work?
</pre>
</blockquote>
I volunteer to continue developing XSL transformations of the NeXus XML
meta-DTDs and instrument definitions, and to demonstrate them on a
separate "downstream" JSP site that acts on artefacts directly drawn
from the official NeXus site. (It has to be completely "downstream" so
that it plays the role of unbiased dynamic consumer of XML artefacts
from NeXus.)<br>
<br>
I volunteer to then look into how one can embed the transformed HTML
output back into the official NeXus Wiki (feedback).<br>
<br>
I "unvolunteer" to be involved with managing your CVS, Wiki, or NeXus
XML meta-DTDs or instrument definitions. I can contribute far more in
the role of independent "consumer" of your XML artefacts, which enables
me to digitally test your project artefacts for consistency and
uniqueness.<br>
<br>
One can include my contributed XSL stylesheet by editing each NeXus XML
file and adding: <br>
<pre> <?xml-stylesheet version="1.0" type="text/xsl" href="nexus.xsl"?></pre>
I unvolunteer to do that, whoever is responsible for those files can
easily do it.<br>
<blockquote
cite="midD47D8CA3F077394CA1B65096E5C701660149C319@ORNLEXCHANGE.ornl.gov"
type="cite">
<pre wrap="">P^2
BTW, for those that are curious: I believe that the definitions on the
wiki are *more* correct than those on the html or in cvs.
</pre>
</blockquote>
The HTML ones are not definitions; they are ASCII characters presented
in a web markup language that mixes "data" and "presentation" logic
(mostly inextricably).<br>
<br>
<font color="#ff0000">Only XML files afford digital definition of
data structures.</font><br>
<br>
The single biggest problem with the state of the NeXus project is that
there is no "canonical" source of meta-DTDs and instrument definitions
as XML; dynamic XSL transformation from the canonical nexus XML files
to HTML (or any other format, even to compilable Java) is
straightforward as I've demonstrated, and solves many other problems,
and if opens up a world of powerful possibilities, such as UML
representation of NeXus artefacts (reverse engineering).<br>
<br>
(The second biggest is the lack of data structure inheritance and
polymorphism, followed closely by the lack of W3C standard XML Schema
definitions to achieve the former.)<br>
<br>
Thanks all for the time in ILL for NIAC2006, I enjoyed it, and I
believe significant progress was made.<br>
<br>
regards,<br>
<br>
Darren<br>
<br>
PS: please all keep in mind that the OPAL NBIs are being commissioned
soon; the fastest way I can achieve contributions to NeXus is to
demonstrate my suggestions working on our live machines.<br>
<pre class="moz-signature" cols="72">--
Dr Darren R C Kelly
Data Analysis Developer
Australian Nuclear Science and Technology Organisation
Web: <a class="moz-txt-link-freetext" href="http://www.ansto.gov.au">http://www.ansto.gov.au</a>
Phone: +61 (2) 9717 7055
Post: PMB 1 Menai NSW 2234 Australia
Important: This transmission is intended only for the use of the
addressee. It is confidential and may contain privileged information or
copyright material. If you are not the intended recipient, any use or
further disclosure of this communication is strictly forbidden. If you
have received this transmission in error, please notify me immediately
by telephone and delete all copies of this transmission as well as any
attachments.
</pre>
</body>
</html>