This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Is there a way to relate source tree nodes to result tree nodes?


Well, that would make the error report more informative.  But I would really like to locate the
original node in the source DOM so that I could get the authoring software to jump to that spot.

----- Original Message -----
From: "Robert Koberg" <rob@koberg.com>
To: <xsl-list@lists.mulberrytech.com>
Sent: Saturday, July 28, 2001 2:28 PM
Subject: Re: [xsl] Is there a way to relate source tree nodes to result tree nodes?


> are you possibly looking to re-style the xml with the only change being
> wrapping the offending chunk with something like:
>
> <error>
> a problem
> </error>
>
> Then you could do a search for all errors. Then remove (re-style) the error
> tags as they fix the errors.
>
>
> ----- Original Message -----
> From: <dpenton@arrowsash.com>
> To: <xsl-list@lists.mulberrytech.com>
> Sent: Saturday, July 28, 2001 11:12 AM
> Subject: [xsl] Is there a way to relate source tree nodes to result tree
> nodes?
>
>
> > I am using xslt to generate reports on problems within an xml document.
> (The reported problems are
> > application-specific, and would not be noticed by a validating parser.)  I
> would like to be able to
> > navigate from a node in the result tree back to a related node in the
> source tree, so the user can
> > locate and fix the reported error.
> >
> > More specifically, I receive the source tree as a DOM 2 document from the
> xml authoring tool
> > application (Epic) that calls my java code.  At the moment I generate a
> paper report using xslt.
> > The problem is that the reader of the report has no easy way of
> identifying the exact spots in the
> > original xml instance that caused my xslt transform to report errors.  The
> source document content
> > itself does not have "landmarks" in it that could be used to identify the
> problem elements.  What I
> > would like to do is display the report so that clicking on a "hyperlink"
> in my output report (using
> > some java widget or other on screen) would allow me to navigate back to
> the element that generated
> > that particular reported error.
> >
> > If I understand xslt correctly (which I would certainly not bet the ranch
> on), the identity of the
> > nodes in the source DOM are lost to the xslt transform, and are available
> only as xslt tree objects.
> > I would guess that this is so even if I get the result tree as a DOM 2
> document, in that the xslt
> > transformer cooks up its own result DOM with no navigable relationship
> with the source DOM.
> >
> > I guess I might be able to figure out some way to use the position of
> elements in document order, or
> > change the dtd so that elements have id attributes that I could navigate
> back to, or something.  But
> > it would sure be nice to to have a simpler way to identify the node in the
> source DOM per se that I
> > have at a given spot in the stylesheet.
> >
> > This post looks as clear as mud to me at the moment.  I hope that y'all
> catch the gist of it and can
> > help me out.
> >
> > TIA.
> >
> > David Penton
> > Arrowsash Inc.
> >
> >
> >  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
> >
>
>
>  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
>
>
>


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]