Closed Bug 51601 Opened 25 years ago Closed 22 years ago

XSLT needs project page on www.mozilla.org

Categories

(Core Graveyard :: Tracking, defect, P3)

Product:
Core Graveyard
Component:
Tracking
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: axel, Assigned: axel)

References

(
URL
)

Details

Hi, as the work on XSLT/transformiix is proceeding, we should have a project page. I whacked something up on http://www.numerik.uni-kiel.de/~ah/mozilla/ for starters. Comments on the page? endico, could you tell us what we need to set this up? Is keith, peter and me ok for write access? Or should that be only one or two? Axel
Axel, can you commit this to the docs directory in the CVS? Maybe we can call it, how_to_build.html or something like that. Once done, we can add a link to it from the readme.html file. --Keith
Hi Keith, honestly, I would prefer to check this in as http://www.mozilla.org/projects/xslt/ XSLT needs a page like this, and this is what I mocked it up for. We have enough temporary homes for information, this is where the info is expected. I built the page to mimick the info on the other project pages, and building it is just one part of it. Axel
Axel, who should this be assigned to?
Assigning to me. Dawn, we have zippies now, which should go on mozilla.org, could Peter and I get access to put up the page and the bins? Adding dmose for he had a plan with pvb on the download. Axel
Assignee: kvisco → axel
the xpi files (as with other binaries) should go on the ftp site and not be checked into the web site's cvs. For now, dmose, leaf or I will have to put the files in place for you. In the (hopefully) near future, we should have something in place so you'll have access to add files yourself. Where should these files go? I suggest ftp://ftp.mozilla.org/pub/projects/xslt leaf? Just gave axel access to check in to the web site. see http://mozilla.org/README-cvs.html and http://mozilla.org/README-style.html for further info. Please add an entry for your project to http://mozilla.org/projects/index.html. I created a module in the doc tree for your project so all you should need to do to check out is this: cvs co xslt Also, could you write up a quick how-to for xpinstall that describes what you did to make the xpi files? Mathml folks want to do this too.
that's a fine place for xslt xpis, now, if only we could grant write access to ftp!
so leaf: how should we handle content beneath the projects/xslt dir? How about a subdir for platform, with several binaries, and symbolic links to the current one? Or should we not have a bin history? I don't think we have something as nightlies anyway, but having more than just one would make it easier to reproduce bugs. pub/projects/xslt - Mac - Windows - Linux - Solaris - - transformiix20000906.xpi - - transformiix20000910.xpi - - transformiix.xpi -> transformiix20000910.xpi This is sure a matter of work vs. feature, sadly enough Axel
Status: NEW → ASSIGNED
that looks fine, though i've had mac, windows, unix->(linux, solaris, etc) beat into my head. I don't see a problem breaking the unixen apart.
yes, the www pages are up. The .xpi don't work yet, they look for ftp://ftp.mozilla.org/pub/projects/xslt/[mac,win,linux,solaris]/transformiix.xpi The sample doesn't work yet, because the xsl stylesheet has wrong mimetype, risto, could you set *.xsl to text/xml ? Thanx. I added some magic to the unix Makefiles, to generate the xpi. This depends on my patch added to 22062, see the stuff I did at http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=mozilla%2Fextensions%2Ftransformiix%2Fbuild&file=&filetype=match&who=axel%25pike.org&whotype=match&sortby=Date&hours=2&date=explicit&mindate=10%2F04%2F2000+00%3A00%3A00&maxdate=10%2F04%2F2000+23%3A00%3A00&cvsroot=%2Fcvsroot Leaving status as REMIND, to keep this as a tracking bug. changed URL. Axel
URL: http://www.numerik.uni-kiel.de/~ah/mo... → http://www.mozilla.org/projects/xslt/
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → REMIND
ftp protocol don't use mimetypes.... it's client feature.
Risto, I think Axel was talking about the mime type for the .xsl file at http:// www.mozilla.org/projects/xslt/test.xsl. Axel, regarding the page, can't we get a patch in that simplifies the Windows build, so that IF MOZ_XSL we add Transformiix to the build dirs?
I've created text/xml MIME type to www.mozilla.org for *.xsl.
Status: RESOLVED → REOPENED
Resolution: REMIND → ---
Javascript error on the project page. Line 47 char 2 - installTrigger is undefined. Dowloading therefore impossible (Win 98, i.e.5)
Of course installing mozilla xpis on IE is not our primary goal. Fixed this to do document.location= for non-lizards. Axel leaf: location of the bins to upload are http://www.av.be/mozilla/[linux|mac|win]/transformiix.xpi and http://www.numerik.uni-kiel.de/~ah/mozilla/transformiix.xpi (solaris)
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → REMIND
Clarification needed: The xpi's available on this page - are they full Mozilla binaries with XSLT enabled, or are they XSLT modules to slot into any build?
I added a comment to the page, hopefully it's clearer now. I also patched the javascript, so we link directly to peters site or mine. Just a hack until the ftp site is up. Axel
Axel, it usually takes a while for changes to moz docs to filter through. Would you mind posting that comment here?
Please change test.xsl so the xsl:stylesheet element includes the mandatory version attribute. And BTW, transformiix should complain about it missing.
when will the latest binaries be back again?
Getting rid of REMIND, greets to Asa ;-) Axel
Status: RESOLVED → VERIFIED
Link to Binaries is BROKEN!
That link should be removed since there is no longer any need to download binaries as they come with the normal mozilla download.
hi, i'm an xml-xsl developer under MS platform, well you made a good job on xslt for mozilla, and it is cool. just one comment: at the example XSL (/test.xsl) there is a param named dummy-param, witch is parsed by your engine, and did not generated errors. i think this IS a problem, cos on any xsl-transformator, it DOES. i think error handling is the main feature of xsl, this should not be broken. btw, keep up the good work ps. download msxml3.1, form 2.5 ms uses the final http://www.w3.org/1999/XSL/Transform namespace as well. please do not flame ms. take care Balint balint@skaelede.hu
test.xsl fixed. Axel
The last sentence of http://www.mozilla.org/projects/xslt/ is > >If you find something wrong on this page, please add it to 51601. > so that's what I'm trying to do here. Anyway, the page says > > Make sure the mime type for both source and stylesheet are set to text/xml > and then later > > Your server sends both the source and the stylesheet with the mime type > "text/xml", right? Be sure it does. > But I'm wondering why this is a requirement. I'd like to make three points: (1) RFC 3023 (available at ftp://ftp.isi.edu/in-notes/rfc3023.txt) and also FAQ pages such as http://www.ucc.ie/xml/#mime suggest that the proper mime type for XSL stylesheets should be "application/xslt+xml". An argument could also be made for "application/xml", and there seems to be some momentum behind "text/xslt+xml". Wouldn't it make sense for Mozilla to accept any of these? (in addition to "text/xml") (2) For that matter, why shouldn't Mozilla accept just about any mime type so long as it is specified as an XSL stylesheet? I mean by something like: > > <?xml-stylesheet href="whatever.xsl" type="text/xsl"?> > I've asked the webmaster at work to change the MIME type for .xsl files from "application/xml" to "text/xml" just to make Mozilla happy, but my personal pages are served by my ISP (Mindspring, over which I have little control). I feel foolish telling visitors to my personal site to either use IE5+MSXML or, if they want to use Mozilla/Netscape, to download the xml and xslt files to their disk and open the local copy. (3) Regardless of how you feel about points (1) and (2), please explain your rational on this page. Just put in a short blurb about why Mozilla is behavinig correctly even though it (seems to) contradict RFC 3023. Or provide a link to some W3C document that confirms Mozilla's choice of mime-type requirements, because I have been unable to find one myself. thanks, -bassclar
I'll update the page soon, I have a bunch of stuff in my head. To clear this out, both the document and the stylesheet need to be sent with a mimetype that mozilla associates with XML. Those are: text/xml, application/xml (and application/xhtml+xml, AFAICT) On the XSLT specific mimetypes, quoting the rfc 3023, 8.17 Application/xslt+xml: However, no content type has yet been registered for XSLT and so this media type should not be used until such registration has been completed.
I played a bit with the XSLT module in Mozilla a short while ago, and found that in order to have the result tree displayed as HTML, it was required that the namespace of the tags should be (an official namespace I cannot remember now) instead of just producing stock HTML as in IE. I think that this should be explicitly stated, since it took me a while to figure out, so others might have problems too.
REMIND is deprecated per bug 35839. Reopening and changing component to Tracking.
Status: VERIFIED → REOPENED
Component: XSLT → Tracking
Resolution: REMIND → ---
http://www.mozilla.org/projects/xslt/ says: Make sure the mime type for both source and stylesheet are set to a XML mimetype, namely text/xml or application/xml. But http://www.mozilla.org/projects/xslt/test.xml contains the line: <?xml-stylesheet type="text/xsl" href="test.xsl"?> Shouldn't be type= be the mime type?
Supporting text/xsl as type in the PI is one fragment of legacy support we do. Mainly, the standalone version knows only this one, so our examples stick to it. I fail to see that type is really MIME type in the spec, but that may be just me. Anyway, parsing XML is different from interpreting the PI, so parsing XML is really strict as far as MIME types go, but the PI is interpreted laid back.
The devedge link has changed. Happily there is a redirect at the old url, but the link should be updated.
fixed, thanx for the hint. Give it some time to stage.
fixed
Status: REOPENED → RESOLVED
Closed: 25 years ago → 22 years ago
Resolution: --- → FIXED
The link to contributors.html is broken.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.