This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: A new twist on attributes vs elements
- To: <xsl-list at mulberrytech dot com>
- Subject: Re: A new twist on attributes vs elements
- From: "Terris" <terris at terris dot org>
- Date: Mon, 13 Nov 2000 09:54:18 -0800
- References: <000d01c04d08$a7a10a40$1d43a118@rochester.rr.com>
- Reply-To: xsl-list at mulberrytech dot com
I agree with you about prefering attributes
but I ran into the case where
column names don't follow xml-names. For
example depending on the vendor the names
can contain spaces.
Which means you can't use column names
as element names either.
Major bummer...
This is what I had to settle with...
<column name='foo'>data</column>
You could put the data in an attribute
as you like....
Furthermore if a column value is null how
would you represent that with attributes.
e.g.
<column name='foo' xsd:isnull='true'/>
I'm not sure if the XSD spec supports null
attribute values.
----- Original Message -----
From: "Melvyn Rosengarden" <melrose@rochester.rr.com>
To: <xsl-list@mulberrytech.com>
Sent: Sunday, November 12, 2000 4:28 PM
Subject: A new twist on attributes vs elements
> I have seen a great deal of discussion recently about converting return
sets
> from SQL ( cursors, recorsets, datawindows) into XML strings. All of the
> examples extract the column names of the return set and create XML with
> them. While this method is probably more efficient for storing and
> retrieving XML data in a relational database it is inferior when it comes
to
> navigating the DOM. I would much prefer to work with attributes (when
they
> make sense) than a myriad of embeded elememts. Has anyone else recognized
> this as an issue and if so how did you resolve it...TIA
>
>
> "You already have zero privacy -- get over it !!
> Melvyn Rosengarden
> melrose@rochester.rr.com
>
>
> XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
>
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list