Re: Re: XSLT Transformation .NET

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!)

Karl..

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
> > http://www.saxonica.com/