RE: [xsl] Validation XSLT using XSLT 1.0

["Michael Kay" <mike@xxxxxxxxxxxx>]

If you use the option -l (lowercase L) on the command line to switch line
numbering on, you can use the saxon:line-number() and saxon:column-number()
extension functions to obtain the line/column number of a node in the source
document.

Michael Kay
http://www.saxonica.com/ 

> -----Original Message-----
> From: Ganesh Babu N [mailto:nbabuganesh@xxxxxxxxx] 
> Sent: 10 July 2008 12:20
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject: Re: [xsl] Validation XSLT using XSLT 1.0
> 
> Hai All,
> 
> As suggested by James, I am looking at the Schematron. I do 
> not know whether i can ask the question related to Schematron 
> here. But I am using Saxon to the process it. So I am asking it here.
> 
> Is there any possible to get the XML filename, line number 
> and column number of the node matching in the pattern?
> 
> The below process will give an idea of how I am using saxon 
> to get the schematron error report.
> 
> java -jar saxon9.jar -s:test.sch -xsl:iso_svrl.xsl 
> -o:test.xsl java -jar saxon9.jar -s:%1.xml -xsl:test.xsl 
> -o:%1-error.xml
> 
> Regards,
> Ganesh
> 
> 
> On 7/3/08, James Fuller <james.fuller.2007@xxxxxxxxx> wrote:
> > you might want to see if schematron is a better 'starting 
> point' for 
> > these kinds of validating stylesheets as well.
> >
> > hth, Jim Fuller
> >
> > On Thu, Jul 3, 2008 at 10:33 AM, Michael Ludwig 
> <mlu@xxxxxxxxxxxxx> wrote:
> >> Abel Braaksma schrieb:
> >>>
> >>> Michael Ludwig wrote:
> >>>>
> >>>>> 3. How to find non-ascii characters in the XML file and 
> report an 
> >>>>> error using XSLT.
> >>>>
> >>>> Don't use XSLT for this. Add the following XML 
> declaration to your 
> >>>> input documents:
> >>>>
> >>>>    <?xml version="1.0" encoding="us-ascii"?>
> >>>>
> >>>> This will ensure the document won't get parsed unless it is pure 
> >>>> ASCII.
> >>>
> >>> Yet may still contain higher characters, which then will 
> be escaped 
> >>> using numerical entity references... So, though the file will be 
> >>> US-ASCII, the contents does not necessarily fit in US-ASCII and 
> >>> still get parsed well.
> >>
> >> That's true. I was lumping together the notions of 
> character set and 
> >> character encoding.
> >>
> >> From the OP's specification, however, it's not entirely 
> clear which 
> >> one is the requirement here. Unless you suppose he'd have written 
> >> "seven-bit clean bytes" instead of "non-ascii characters" had he 
> >> wanted to talk about bytes instead of characters.
> >>
> >> Michael Ludwig