> I briefly considered this, but I think we should rather go for the
> opposite: let the XSLT translator take files as input. If directory
> input is desired, it can always be set on top of unxml.
That is probably a better solution, if the xslt translator presents a
file as output, giving it a dir
Hi,
On Thu, Apr 07, 2011 at 09:09:35PM +0100, Michael Walker wrote:
> > I don't think the XSLT translator should present a directory tree as
> > output. Nothing in XSLT requires the output to be XML.
>
> Aha, I had a feeling I was misunderstanding something somewhere. In
> that case, xslt would
Hi,
On Thu, Apr 07, 2011 at 01:46:02PM +0100, Michael Walker wrote:
> * Read support in unxmlfs
> unxmlfs takes an xmlfs-compatible directory tree and turns it
> into an XML file, thus reading will be done via libtrivfs, with no
> write support (I see no need/use for that).
I do.
The GSo
> Well, if you need the exact same code, this is a pretty good indication
> that it probably shouldn't be in the XSLT translator at all... Working
> on top of a directory tree would only make sense if it would actually
> use the provided structure directly, rather than first serializing it.
>
> Or
Hi,
On Wed, Apr 06, 2011 at 03:43:15PM +0100, Michael Walker wrote:
> I did originally just plan to do xmlfs, but then I realised that most
> of the nontrivial code in the xslt translator and in unxmlfs would be
> the same - the directory-tree-to-XML parser, which shouldn't really be
> too hard.
> I did originally just plan to do xmlfs, but then I realised that most
> of the nontrivial code in the xslt translator and in unxmlfs would be
> the same - the directory-tree-to-XML parser, which shouldn't really be
> too hard. The only other nontrivial part of the xslt code is the
> libnetfs-base
> So the idea is that one would launch an XSLT translator, with a XSLT
> style sheet as input, on top of an xmlfs directory, and the result would
> be a file representing the output of the XSLT processor?
Yes, that's what I was thinking. Though, being able to run it on top
of an XML file should be
olafbuddenha...@gmx.net, le Tue 05 Apr 2011 22:24:57 +0200, a écrit :
> So the idea is that one would launch an XSLT translator, with a XSLT
> style sheet as input, on top of an xmlfs directory,
No, I'd rather say on top of an xml file.
Samuel
On Sun, Apr 03, 2011 at 02:10:33AM +0200, Samuel Thibault wrote:
> Michael S. Walker, le Sun 03 Apr 2011 00:30:32 +0100, a écrit :
> > What's the correct way to produce a patch? I'm using git for version
> > control (if that's relevant).
>
> Then git diff.
No, git format-patch is much better.
-
Hi,
On Sun, Apr 03, 2011 at 12:30:32AM +0100, Michael S. Walker wrote:
> On Fri, 1 Apr 2011 19:41:28 +0200 wrote:
> > > * Support for XSLT transformations
> >
> > Not sure how that would fit?...
>
> It was an idea proposed in the TODO file, though that might be better
> as a separate transla
Michael S. Walker, le Sun 03 Apr 2011 00:30:32 +0100, a écrit :
> On Fri, 1 Apr 2011 19:41:28 +0200
> wrote:
> > On Tue, Mar 29, 2011 at 10:57:44PM +0100, Michael Walker wrote:
> >
> > > * Fix all gcc warnings [done]
> >
> > Send the patch(es) :-)
>
> What's the correct way to produce a patch?
On Fri, 1 Apr 2011 19:41:28 +0200
wrote:
> Hi,
>
> On Tue, Mar 29, 2011 at 10:57:44PM +0100, Michael Walker wrote:
>
> > * Fix all gcc warnings [done]
>
> Send the patch(es) :-)
What's the correct way to produce a patch? I'm using git for version
control (if that's relevant).
> > * Suppo
Hi,
On Tue, Mar 29, 2011 at 10:57:44PM +0100, Michael Walker wrote:
> * Fix all gcc warnings [done]
Send the patch(es) :-)
> * Support for XSLT transformations
Not sure how that would fit?...
The rest makes sense as far as I can tell; so I hope to see a good
application soon :-)
-antrik-
Michael Walker, le Tue 29 Mar 2011 22:57:44 +0100, a écrit :
> Finally, even if this doesn't get picked as a GSoC task (after I send
> off my application), I still intend to do this over the summer to
> better learn Hurd programming, and so either way there will be an
> improved xmlfs this year :)
14 matches
Mail list logo