Re: [xml] Canonical XML
- From: Aleksey Sanin <aleksey aleksey com>
- To: veillard redhat com
- Cc: xml gnome org
- Subject: Re: [xml] Canonical XML
- Date: Thu, 28 Feb 2002 10:47:13 -0800
Please, find examples bellow. The brief description is that AFAIK
if we evaluate XPath _expression_ against document then the document
should be modified at least as follows:
1) default attributes added to element nodes
2) namespaces from ancesstors are propagated to the node
These new added nodes could be included in the resulted XPath nodes set for
further processing.
Aleksey.
It turns out that libxml has no full XPath implementation:
sounds a bit excessive.
I am sorry I did not want to offend you. But I do see some missed functionality
and this means that libxml does not follow XPath standard.
1) "parent::ietf:e1" does not include any e1 namespaces
Give an example, sounds strange.
Example:
------------
## xml doc:
<doc xmlns="http://www.ietf.org" xmlns:w3c="http://www.w3.org">
<e1 a=b>
<e2 xmlns="" />
</e1>
</doc>
## xpath expr:
(//. | //@* | //namespace::*)
[
self::ietf:e1 or (parent::ietf:e1 and not self::e2)
]
## expected result (attribute nodes included in the result nodes set) :
<e1 a=b xmlns="http://www.ietf.org" xmlns:w3c="http://www.w3.org"></e1>
## libxml result (attribute nodes included in the result nodes set):
<e1 a=b></e1>
##
http://www.w3.org/TR/xpath#namespace-nodes :
The element is the
parent
of each of these namespace nodes; however, a namespace
node is not a child of its parent element.
...
This means that an element will have a namespace node:
-
for every attribute on the element whose name starts with
xmlns:
;
-
for every attribute on an ancestor element whose name starts
xmlns:
unless the element itself or a nearer ancestor
redeclares the prefix;
-
for an xmlns
attribute, if the element or some
ancestor has an xmlns
attribute, and the value of the
xmlns
attribute for the nearest such element is non-empty
## CVS version of file xpath.c, function xmlXPathNextParent() :
case XML_NAMESPACE_DECL:
/*
*
TODO !!! may require extending struct
_xmlNs with
*
parent field
* C.f. Infoset case...
*/
return(NULL);
2) namespaces from the parent element are not included
in the child's namespaces axis
Hum, strange. I'm pretty sure it works well, I even have some XSLT test
cases for those.
See the example above.
3) default attributes from inner DTD are not included
in the result nodes set
Yes they are if you give the parser the required flags to add them to
the tree.
## xml doc:
<!DOCTYPE doc [
<!ATTLIST e1 b (default|preserve) 'b1'>
]>
<doc>
<e1 a=a1>
</e1>
</doc>
## xpath expr:
(//. | //@* | //namespace::*)
[
self::ietf:e1 or parent::ietf:e1
]
## expected result (attribute nodes included in the result nodes set) :
<e1 a=a1 b=b1></e1>
## libxml result (attribute nodes included in the result nodes set):
<e1 a=a1></e1>
##
http://www.w3.org/TR/xpath#attribute-nodes:
A defaulted attribute is treated the same as a specified attribute.
## CVS version of file xpath.c, function xmlXPathNextAttribute():
/**
* xmlXPathNextAttribute:
* @ctxt: the XPath Parser context
* @cur: the current attribute in the traversal
*
* Traversal function for the "attribute" direction
*
TODO: support DTD inherited default attributes
*
* Returns the next element following that axis
*/
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]