Re: [xsl] XPath Best Practice: Getting the processor to detect misspelled tag names in XPath expressions

Subject: Re: [xsl] XPath Best Practice: Getting the processor to detect misspelled tag names in XPath expressions
From: Florent Georges <lists@xxxxxxxxxxxx>
Date: Fri, 22 Feb 2008 15:12:48 +0100 (CET)
"Costello, Roger L." write:

> Using features from the host language is not an ideal
> situation.  The consequence of using
> host-language-specific features is that the XPath is not
> portable: for each host language the XPath must be
> redesigned using capabilities from the host language.

  It doesn't sound to me that the above makes XPath
expressions non-portable.  But XPath does not define
everything, so if you want something that relies outside
XPath, you have to use features from outside XPath.  For
instance to "validate" expressions against a schema.

  Here is a simple example.  Let's say someone wants to get
the rating of a book.  So she writes:

    /Book[ISBN eq $id]/@rate

  But your schema doesn't define such an attribute.  So that
should be an error, right?

    <xsl:for-each select="doc('ratings.xml')">
       <xsl:sequence select="/Book[ISBN eq $id]/@rate"/>
    </xsl:for-each>

  Should it still be ?-)

  My own point of view is that XPath defines yet a lot of
things, but delegates also a lot, to the host language.  And
that's the beauty of it, that's why it can integrate so
naturaly, I think.

  Sometimes that sucks.  The most obvious example I can
think of is the "statically known namespaces" component of
the static context.  The XPath expression "/p:Book" does
rely on the host language, heavily.  You cannot just past it
into your prefered Java file and use some XPath engine, you
have to bind the namespace prefix before being able to
evalute the expression.

  Regards,

--drkm


















      _____________________________________________________________________________ 
Ne gardez plus qu'une seule adresse mail ! Copiez vos mails vers Yahoo! Mail http://mail.yahoo.fr

Current Thread