RE: Is this strategy for runtime fixed-width->xml con

Ok, this is interesting (I'll have to read this fully later), but let me
ask some follow-on questions:

If I'm restricted to XSLT 1.0, how viable is my approach?  I'm guessing
if my input is truly "fixed", with no repeating groups or conditional
transformation blocks, this should work fine.  If I have either
repeating groups or conditional transformation blocks, that makes it a
little more complicated, but I'm not sure how much more.

This article was written around the Saxon 8.1 timeframe.  Would this
article change significantly if it was updated to reflect more recent
Saxon releases?

Concerning features of Saxon, I'm not certain exactly what
"schema-aware" means.  Does that imply less schema-related functionality
than in XSLT 1.0, like namespaces (unlikely, I would think), or does it
simply refer to the schema validation features?  I can't find a clear
statement about this.

> -----Original Message-----
> From: Michael Kay [mailto:mike@xxxxxxxxxxxx]
> Sent: Friday, April 28, 2006 2:43 PM
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject: RE:  Is this strategy for runtime
> fixed-width->xml conversions worthwhile?
>
> You might be interested in
>
> http://www.idealliance.org/proceedings/xml04/papers/111/mhk-paper.html
>
> to see how far this kind of approach can take you. What you
> are proposing is much simpler. As you say, it could be done
> in a variety of ways, but it's certainly not overkill to use
> XSLT for this.
>
> Michael Kay
> http://www.saxonica.com/
>
> > -----Original Message-----
> > From: Karr, David [mailto:david.karr@xxxxxxxx]
> > Sent: 28 April 2006 22:09
> > To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> > Subject:  Is this strategy for runtime fixed-width->xml
> > conversions worthwhile?
> >
> > I'm wondering about viable strategies for runtime conversion of
> > fixed-width messages into XML (and back, I suppose).  I
> know there are
> > various frameworks that do this, but it occurred to me this
> could be
> > done entirely with XSLT.
> >
> > The stylesheet would have a single template element, which
> would cover
> > the entire message format (unless there are conditional
> pieces).  The
> > input to the stylesheet could be empty, and a single stylesheet
> > parameter would be the "input"
> > to the stylesheet.  Each reference in the template to the
> input would
> > use the "substring()" function, to pull the appropriate
> portion of the
> > parameter into the element.
> >
> > I'm not sure exactly how the reverse direction would work, however.
> >
> > Is this approach at all worthwhile?  What are specific
> problems with
> > this idea?