469,934 Members | 1,783 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,934 developers. It's quick & easy.

Grabbing the 'node depth' when importing XML as a dataset?

I've decided that instead of doing an XSLT transformation on a file, I might
be better off bringing it in as a dataset and having a bit more direct
control over it at that point.

The question I have is if one can determine the node depth as they import
the XML. I could, obviously, just put the node depth in as another xml
element at the time of creation, which really isn't a big deal, but thought
I'd see if I could do it on the import side first.

-Darrel

--
================================================== ===============
Win prizes searching google:
http://www.blingo.com/friends?ref=hM...nTqhv-2GE1FNtA
Nov 15 '06 #1
8 2743
If you use XmlReader to read the file it has a Depth property which shows
that depth of each node. If you use XmlDocument you can determine the depth
of a node by walking up the parent chain.

-Helena

"darrel" wrote:
I've decided that instead of doing an XSLT transformation on a file, I might
be better off bringing it in as a dataset and having a bit more direct
control over it at that point.

The question I have is if one can determine the node depth as they import
the XML. I could, obviously, just put the node depth in as another xml
element at the time of creation, which really isn't a big deal, but thought
I'd see if I could do it on the import side first.

-Darrel

--
================================================== ===============
Win prizes searching google:
http://www.blingo.com/friends?ref=hM...nTqhv-2GE1FNtA
Nov 15 '06 #2
If you use XmlReader to read the file it has a Depth property which shows
that depth of each node. If you use XmlDocument you can determine the
depth
of a node by walking up the parent chain.
I assume that both of these would mean I'm leaving the data as XML and
navigating it via XPATH as opposed to just bringing it in as a dataset and
looping through it?

If so, would it be more efficient to just export the depth as an XML element
in the source so it can be brought in as a dataset (or is xpath navigation
as efficient as looping through a dataset sequentially?)

-Darrel
Nov 15 '06 #3
Yes, you would have to leave the data as XML, although you don't have to use
XPath. Navigating the data sequentially is efficient in both XmlReader nd
XmlDocument. With XmlReader it will be more efficient but maybe a little bit
more work with the API.

Thanks,
-Helena
"darrel" wrote:
>
If you use XmlReader to read the file it has a Depth property which shows
that depth of each node. If you use XmlDocument you can determine the
depth
of a node by walking up the parent chain.

I assume that both of these would mean I'm leaving the data as XML and
navigating it via XPATH as opposed to just bringing it in as a dataset and
looping through it?

If so, would it be more efficient to just export the depth as an XML element
in the source so it can be brought in as a dataset (or is xpath navigation
as efficient as looping through a dataset sequentially?)

-Darrel
Nov 15 '06 #4
Dataset does not provide more control than an xml document.

Anyway, what you can do is look at XmlDataDocument, for it might be
easier to use if you're used to dealing with data in datasets.

Helena wrote:
Yes, you would have to leave the data as XML, although you don't have to use
XPath. Navigating the data sequentially is efficient in both XmlReader nd
XmlDocument. With XmlReader it will be more efficient but maybe a little bit
more work with the API.

Thanks,
-Helena
"darrel" wrote:
If you use XmlReader to read the file it has a Depth property which shows
that depth of each node. If you use XmlDocument you can determine the
depth
of a node by walking up the parent chain.
I assume that both of these would mean I'm leaving the data as XML and
navigating it via XPATH as opposed to just bringing it in as a dataset and
looping through it?

If so, would it be more efficient to just export the depth as an XML element
in the source so it can be brought in as a dataset (or is xpath navigation
as efficient as looping through a dataset sequentially?)

-Darrel

Nov 16 '06 #5
Dataset does not provide more control than an xml document.

Well, more control using VB.net directly, rather than XSLT. That's usually a
plus in my book. ;o)

-Darrel
Nov 16 '06 #6
well a dataset isn't going to give you what XSLT does.. i'm not exactly
sure what you're trying to do, but if you're attempting to actually
render an xml document a certain way, then a dataset isn't going to
help you. if you are trying to transform an xml doc into a different
xml doc, then ok.. but even still, the dataset is a really clunky way
to achieve this.

darrel wrote:
Dataset does not provide more control than an xml document.

Well, more control using VB.net directly, rather than XSLT. That's usually a
plus in my book. ;o)

-Darrel
Nov 16 '06 #7
well a dataset isn't going to give you what XSLT does.. i'm not exactly
sure what you're trying to do, but if you're attempting to actually
render an xml document a certain way, then a dataset isn't going to
help you. if you are trying to transform an xml doc into a different
xml doc, then ok.. but even still, the dataset is a really clunky way
to achieve this.
I dunno. The more I work XSLT, the less I see it as being very efficient in
terms of development and maintenance.

Typyically, we use it to grab data from an XML file, and then render is on
part of our web page.

XSLT works, but in this example, I'm trying to do a variety of things:

- pass and decode encoded HTML
- create unique links on the page for each node of the XML
- Implement CSS/javascript based collapsable tree views

Now, XSLT can do all of this just fine, and does it well. But it involves
passing a bunch of variables to the XSLT file and then doing a lot of the
logic via XSLT. We're finding that it seems to make more sense for us to
leave the logic in VB.net, as that's what more people around here are
familiar with.

I'm still fighting through this one...I do want to get it working in
XSLT...maybe I'll change my mind once I get through it. ;o)

-darrel
Nov 17 '06 #8
yeah. although xslt is built for exactly what youre trying to do, it
may be easier for you to use XmlDataDocument (not XmlDocument) to load
your xml file, and then bind a .net control's datasource to the DataSet
property of your XmlDataDocument, and then handle it that way. A lot
of this depends on the xml file of which will be easier. I've found
that with really complex hierarchy's in xml files, xslt is much more
flexible. Remember that DataSets symbolize relational data, not
hierarchical data.


darrel wrote:
well a dataset isn't going to give you what XSLT does.. i'm not exactly
sure what you're trying to do, but if you're attempting to actually
render an xml document a certain way, then a dataset isn't going to
help you. if you are trying to transform an xml doc into a different
xml doc, then ok.. but even still, the dataset is a really clunky way
to achieve this.

I dunno. The more I work XSLT, the less I see it as being very efficient in
terms of development and maintenance.

Typyically, we use it to grab data from an XML file, and then render is on
part of our web page.

XSLT works, but in this example, I'm trying to do a variety of things:

- pass and decode encoded HTML
- create unique links on the page for each node of the XML
- Implement CSS/javascript based collapsable tree views

Now, XSLT can do all of this just fine, and does it well. But it involves
passing a bunch of variables to the XSLT file and then doing a lot of the
logic via XSLT. We're finding that it seems to make more sense for us to
leave the logic in VB.net, as that's what more people around here are
familiar with.

I'm still fighting through this one...I do want to get it working in
XSLT...maybe I'll change my mind once I get through it. ;o)

-darrel
Nov 17 '06 #9

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by Mike Collins | last post: by
reply views Thread by Mike Collins | last post: by
2 posts views Thread by Mike Collins | last post: by
6 posts views Thread by datamodel | last post: by
7 posts views Thread by Arancaytar | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.