>From: "Watson, John" <JWatson@xxxxxxxxxxxxxxxxxxx>
>To: "'XSL-List@xxxxxxxxxxxxxxxxxxxxxx'" <XSL-List@xxxxxxxxxxxxxxxxxxxxxx>
>Subject: namespace prefixes and Xpath/XSLT
>Date: Mon, 7 Apr 2003 09:23:00 +0100
>Can anyone help me with this? I am investigating the experimental DOM3
>XPath interface as implemented in Xalan-J 2.4.1, and how this plays with
>namespaces.
>
>If I have this document:
>
><?xml version = "1.0"?>
><foo:a xmlns:foo = "urn:foo" xmlns = "urn:foo">
> <b><c/></b>
></foo:a>
>
>And I initialise the XPath Namespace (using XPathNSResolver) from the root
>element, so it is aware of foo and the default namespace, the following
>XPath pattern finds a match:
>
>/a/b/c
>
>whereas any patterns containing namespace prefixes such as
>
>/foo:a/foo:b/foo:c
>
>or
>
>/foo:a/b/c
>
>do not find a match. This is the reverse of what I would have expected.
>Does this surprise anyone, or have I misunderstood namespaces anf how they
>are intended to work with XPath? Or is it a Xalan bug? (incidentally, I
>seem to get the same behaviour using the proprietary XPathAPI interface.)
>
>If, on the other hand, I use XPath expressions within match expressions in
>XSLT template rules, behaviour is that I always need to use the namespace
>prefix in the expression (even though I may have defined a default namespace
>in the sheet). i.e. the reverse of the raw DOM XPath behaviour. My
>understanding is that this is correct XSLT 1.0 behaviour, but may change in
>XSLT 2.0. Is this correct?
>
>Thanks in advance for any help!
>
>John Watson
>
>
>**************************************************************************
>Satellite Information Services Limited Registered Office:
>17 Corsham Street London N1 6DR, Company No. 4243307
>
>The information in this e-mail (which includes any files
>transmitted with it) is confidential and may also be legally
>privileged. It is intended for the addressee only. Access to
>this e-mail by anyone else is unauthorised. It is not to be
>relied upon by any person other than the addressee except
>with prior written approval of an authorised representative of
>SIS. If no such approval is given, SIS will not accept any
>liability (in negligence or otherwise) arising from any third
>party acting, or refraining from acting, on such information.
>
>Unauthorised recipients are required to maintain confidentiality.
>If you have received this e-mail in error please notify the
>sender immediately, destroy any copies and delete it from your
>computer system.
>**************************************************************************
--
======================================================================
B. Tommie Usdin mailto:btusdin@xxxxxxxxxxxxxxxx
Mulberry Technologies, Inc. http://www.mulberrytech.com
17 West Jefferson Street Phone: 301/315-9631
Suite 207 Direct Line: 301/315-9634
Rockville, MD 20850 Fax: 301/315-8285
----------------------------------------------------------------------
Mulberry Technologies: A Consultancy Specializing in SGML and XML
======================================================================
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
|