[Om3] OpenMath 3 XSLT revival, and questions

[David Carlisle]

On 15/02/2011 16:43, Christoph LANGE wrote:
> Hi David,


>
> @David, now for the issues I encountered:
>
> I can't judge whether the changes to the CD-specific XSLTs that you have
> made in the OpenMath 3 branch and in www/cdfiles2/xsl are in sync.

neither can I:-)

As you know there was a period when it wasn't really clear which set 
were being used and so fixes probably got applied to one or the other or 
both.  later in the (mathml3) process once we'd committed to basing 
things on the OM2 CDs there were I think some fixes specifically to fix 
things that came up while testing rewrites to strict content mathml
(which worked by translating to openmath and then back to mathml) so 
those later fixes would (I hope) all be in the om2 branch currently.

   An
> easy solution would be to assume that the current version of all
> www/cdfiles2/xsl/CDNAME.xsl files is up to date, and replace the
> formerly-OpenMath3-XSLTs with them.  But I'm not so sure about that, as
> today I did notice one fix in om2cmml.xsl that you made in OM3 but not
> in OM2, but which was not OM3-specific.

probably you should do that, and I'll try to get time to run through the 
change logs of the OM3 ones to see if anything I did there should be 
moved across.

>
> In some places in cd.xsl I noticed that you added
>
> cd:CDDefinition[1]/cd:Name[1]
>                            ^^^
>
> … whereas in other places you didn't add it.  Do we have invalid CD
> files that have two names per symbol?

I would guess that we must have had, as I doubt that I would have added 
the [1] there unless it was generating an error without it, and as you 
say that would apparently mean the input was invalid. I can't remember, 
but one possible place that that could be useful would be processing 
submissions by the contribution form. If the contributed CD isn't quite 
valid you probably still want the html generation to work as far as 
possible rather than it fail with some xpath error that two items have 
been selected when one is expected.

>
> In my code I realised test-file-exists via boolean(document(...)), i.e.
> without using java.io.File.  That does not exactly do the same job but
> IMHO works well enough.  The problem with java.io.File is that the free
> version of Saxon>= 9.2 no longer supports that convenient way of
> calling Java code.  And I suppose that we will eventually switch to the
> latest Saxon.

yes we should get rid of saxon/java dependencies as far as possible, 
best would be to use doc-available() I think.
>
> Cheers,
>
> Christoph
>

David


________________________________________________________________________
The Numerical Algorithms Group Ltd is a company registered in England
and Wales with company number 1249803. The registered office is:
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.

This e-mail has been scanned for all viruses by Star. The service is
powered by MessageLabs. 
________________________________________________________________________