Re: [xsl] Re: XSLT Transformation .NET

Subject: Re: [xsl] Re: XSLT Transformation .NET
From: Karl Stubsjoen <kstubs@xxxxxxxxx>
Date: Sun, 4 Dec 2005 12:46:31 -0700
Precisely what Bryan states, it is just difficult to setup global
transformation rules.  I, for example, might display all field
elements the same exact way, so I'd write a single match on "field",
then of course the beauty is that if I want to handle a specific field
match differently, with the appropriate xpath, I match on "who's
fieldname is 'peachy' ".  (I'm preaching to the choir, I know!)


Oh, by the way, I solved my stupid transformation problem in .NET.
Now I'm on a quest to find a better way to persist data in .NET to
something I think is more useful.  Any hints on this?

On 12/4/05, bryan rasmussen <rasmussen.bryan@xxxxxxxxx> wrote:
> maybe because it's easier to write a generic xslt for  persisted
> datasets if they are all named the same. otherwise one would have to
> find a structural pattern to the tree independent of naming to order
> anything that came out in this way.
> On 12/4/05, Michael Kay <mike@xxxxxxxxxxxx> wrote:
> > > Didn't anyone ever mention in the
> > > microsoft camp there that xml elements named as field names is a bad
> > > idea?  That it is a much more useful source if the xml elements are
> > > all named the same?
> >
> > Oddly, over on xml-dev people are busy complaining about formats that do
> >
> > <div class="monty">
> >   <span class="python"/>
> > </div
> >
> > rather than
> >
> > <monty><python/></monty>
> >
> > Why do you think it's bad to use field names as element names?
> >
> > Michael Kay
> >

Current Thread