You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Matthew Cordes <mc...@maine.edu> on 2000/05/26 01:19:25 UTC

If there is a bug in Xalan, report it. Don't complain here

Hello Paul

> What Xalan mailing list? I searched your Web site up and down, and there's
> no xalan-users list to be seen. Moreover, if I email
> xalan-users-subscribe@xml.apache.org (or xalan-users-request) I get "user
> unknown". The only Xalan mailing list I can find any hint of is the one for
> developers, which I'm not.

You could send the powers that be at xml.apache.org an email requesting
such a mailing list.  If you do this, I will do the same as a list
dedicated to Xalan-user's would be great and quite useful.

> They came with strong statements to the effect that they supported the
> *full* XML/XSLT standards,
> and this inability to inline documents in other documents when I've heard
> repeatedly this is a capability of XML, strongly implies that these strong
> statements were wrong.

What do you mean by inline documents?  Do you  mean xsl:include and
xsl:import?  They work fine for me.  I'm using Xalan-1.0.1 on Debian
linux 2.2 (potato).


> And how do I do that? Nobody has deigned to provide a xalan-users list to
> get feedback from end-users of Xalan. Then again, I get the distinct
> impression that open source developers rarely think about end-users, and
> think only of the development team, nine times out of ten, with the
> apparent exception of the Cocoon development team.

It seems to me that the Xalan-devel list ( which does exist ) would be
the place to make bug reports, etc.  These are the wonderful people who 
write Xalan.  If you sent such a request to other users it seems ( at 
least to me ) you would get a much less learned/experience response.

> I did it exactly the way the tutorial described. Check out the links I
> provided, particularly the foil67.html one. That one contains exactly what
> I did: <xsl:apply-templates select="document($somevar)"\> with somevar
> pointing to
> an XML file.

This may just be an email typo, but don't you want a '/' above instead of
the '\'?  I hope this isn't your problem?

> I didn't make any such declaration. I lamented that I'm now unsure
> *whether* it is the salvation or the doom of my project. Obviously you
> didn't even read my post completely and clearly before deciding to launch
> all missiles. Hothead.

Dude, I hope you filter your email.  Hostility such as this leads to much
hate mail.  

> I can't hire anyone, on this budget. I could try to do it myself, if I had
> enough spare time to learn all of the APIs and all of the internals of
> Xalan, which I don't. Isn't Xalan 1.0.1 supposed to be a *finished
> product*? I should not be encountering error messages that basically say
> "This feature is not yet implemented. Sorry for wasting your download time
> or claiming to be complete or claiming the technology is now mature enough
> for production use. Try again next year, and the year after that, and
> maybe, just maybe, you'll be able to finish your project by the year 2010."

Finished product?  Ha! No!  Didn't you see the warnings.  Xalan's page is
full of them.  Much of the API is subject to change whenever the
developers feel it is appropriate.  Furthermore it will probably a year
or more before xml/xslt are even supported by all web browser and in high
demand, until then consider yourself lucky to have the chance to mess
with a budding new technology. 


> An XML-enabled Web site. With some documents using links that are meant to
> actually embed one document in another, or a data set in a document. The
> idea being the XSL template for the embedding tag reads in the document
> using document() and then runs it through processing; the style sheet for
> the embedding document formats into HTML both the embedding document and
> the embedded document or data, which allows the same document to appear
> with different formatting or style in different embedded uses as well as as
> a stand-alone document. All stuff XML and XSLT are supposedly capable of
> doing. That foil67.html link shows a tutorial based on the XSLT
> Recommendation and XPath Recommendation explaining how to do this. If it's
> based on the W3C Recommendations, it can't be *wrong*, so either it is
> *lying*! or there is a bug/"not yet implemented" in Xalan that shouldn't be
> there.

I do this already with Xalan and servlets.  Have you read the spec?  Why
not post some code?  You could even email me directly if you wished, I'm
a student with a hectic schedule, but I don't mind helping others.

> Phase 1 is just to compile the XML source locally to HTML which is then
> uploaded to a Web server. (A Xoom.com account, as a matter of fact.)
> Currently it seems easiest to use Xalan for this, since Cocoon AFAIK
> doesn't support an API to call individual transformations from inside
> another Java app, and I need another Java app (written, tested, and working
> except for the Xalan problem) to traverse the directory structure
> incrementally updating changed files. (I'd much rather avoid having to
> explicitly run some app with a bunch of parameters every time I changed an
> XML file; easier to make many changes throughout the XML sources tree, then
> when these are finalized run a program that automates updating the HTML
> files.)

I'm not that hip on cocoon, but can't this be done with a producer
servlet?


> Phase 2 is to set up my own Web server, using Apache and Cocoon, and
> dispense with the compiling step. That can't work until I have a cablemodem
> or other broadband access that can support a Web server's network
> requirements and will be visible to the Linux operating system. And that
> requires waiting for an improvement in the financial situation here. A
> student can't easily afford either a cable-modem or cable ISP rates. (The
> only alternative is free, unlimited space hosting with XML support e.g.
> with Cocoon, and AFAIK there is no such thing. Besides which that has the
> undesirable effect of meaning I can't test things locally and upload the
> changes when they are debugged; instead I'd have to upload every change to
> some remote, perhaps intermittently wonky server somewhere, *then* test
> them, and the test/debug/edit cycle would slow to an unacceptable crawl.
> Imagine having to upload and the download something over the net to fix
> each single error in an XSL file! It simply isn't practical.)

Setting up apache from source is a couple hour job with at least 1 donut
and many coffee breaks.  Even annoying things to set up ( I personally
had a hard time with Tomcat 3.1 ) aren't really that hard.  What OS are
you using?

Couldn't you get a provider with telnet/ssh access and edit/compile your
pages on their machines?


-matt

Re: If there is a bug in Xalan, report it. Don't complain here

Posted by Paul Derbyshire <de...@globalserve.net>.
At 07:19 PM 5/25/00 -0400, you wrote:
>You could send the powers that be at xml.apache.org an email requesting
>such a mailing list.  If you do this, I will do the same as a list
>dedicated to Xalan-user's would be great and quite useful.

I'd be happy to, but there is no (documented) "list-creation-request
address". If there is such an address at all, evidently it is undocumented,
and so before I can email to it, someone needs to kindly provide me with
the address.

>What do you mean by inline documents?  Do you  mean xsl:include and
>xsl:import?  They work fine for me.  I'm using Xalan-1.0.1 on Debian
>linux 2.2 (potato).

No, that's for cascading stylesheets, not for embedding one document in
another; document() is supposed to be for the latter.

>It seems to me that the Xalan-devel list ( which does exist ) would be
>the place to make bug reports, etc.  These are the wonderful people who 
>write Xalan.  If you sent such a request to other users it seems ( at 
>least to me ) you would get a much less learned/experience response.

Yeah but I doubt I can post without subscribing, and I very much doubt I
can post without subscribing *and expect to see the replies*. If I do
subscribe, I'll porobably find my hard disk full of binary attachments
before I know what hit me, and Eudora doesn't seem to delete attachments
when it deletes messages with attachments, so some hidden directory
somewhere would bloat up until my disk filled...

>
>> I did it exactly the way the tutorial described. Check out the links I
>> provided, particularly the foil67.html one. That one contains exactly what
>> I did: <xsl:apply-templates select="document($somevar)"\> with somevar
>> pointing to
>> an XML file.
>
>This may just be an email typo, but don't you want a '/' above instead of
>the '\'?  I hope this isn't your problem?

Yes, you're right, that was a typo in the email; it's correct in my style
sheet file.

>Dude, I hope you filter your email.  Hostility such as this leads to much
>hate mail.  

I'm only ever hostile *back*, so if you see me being hostile, rest assured
it's just an example of what goes around, comes around.

>I do this already with Xalan and servlets.  Have you read the spec?  Why
>not post some code?

I posted the line of XSLT code causing the problem. You even pointed out a
typo I made transcribing it into email.

>I'm not that hip on cocoon, but can't this be done with a producer
>servlet?

I don't even know WTF a "producer servlet" is. In any case, phase 1 doesn't
involve and can't involve any servlets, because it's only at phase 2 that I
will have a Web server operating with which to run a servlet.
And it's at phase 2 that I plan to research servlets and how to set up/use
them and what a "producer servlet" is and ... etc.

>Setting up apache from source is a couple hour job with at least 1 donut
>and many coffee breaks.  Even annoying things to set up ( I personally
>had a hard time with Tomcat 3.1 ) aren't really that hard.  What OS are
>you using?

Dual Win98/Linux, but the computer OEM stuck me with a winmodem, which
means there's no point going to phase 2 until I have a replacement modem --
also, operating a Web site off a PC demands a broadband connection so I
have to hold out for a cable-modem or something of the sort anyway. Until
then, it's phase 1: offline conversion to HTML (preferably without having
to boot into Linux) and upload to a hosting provider with a lot of space
(Xoom; preferably without having to boot back into Windows from Linux).

>Couldn't you get a provider with telnet/ssh access and edit/compile your
>pages on their machines?

On a slow, loaded, wonky and unreliable machine of my ISP's instead of my
own 400MHz 64 megabyte single user machine? With the same software with the
same quirks? I don't think so.
-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  |http://surf.to/pgd.net derbyshire@globalserve.net
_____________________ ____|________                          Paul Derbyshire
Programmer & Humanist|ICQ: 10423848|