Hi Marc,
Scanning the document in this case is not an option, and as namespaces may be
removed, and content shared within the document, maintaining a map of usage is
not trivial in code, CPU or memory.
I do not want to scan the document to build the list of namespaces. The
add(Namespace) method of AbstractElement could add each new namespace to the
specific new XPathNamespaces object which is declared at the document (in my
addition).
So how does this cope with structural chnages. An Element and all of the
children may be added in a single rearrangement, an element may not have a
document when it is being built., and the document may be chnaged after the
element is added, or many other different ways to disturb the structure.
What is needed is a NamespaceContext (but at best not only for jaxen, but that
is an other point) which holds all namespaces that are declared in the
document. And what is needed is code to collect this namespaces in creation of
the document.
Agreed the curren one is tied to Jaxen, and a pluuggable XPath would be a huge
improvement
The Problem with only add namespaces to the document with add(Namespaces) is in
adding of branches. To solve this there might be
1) a more complex strategy to hold namespace declarations for each branch
As I am sure youwould agree this would be costly
2) retrieval of all namespaces from the branch while adding
As I am sure youwould agree this would also be costly
3) add all namespaces of the document of the branch (if it comes from an other
document), because more namespaces than needed should not be a problem
For me point 3 would be enough.
Surely if there are 10 definitions for a given prefix and 10 prefix definitions
for a given namespace and they are all different then that woul be a problem
wouldnt it. Dont you have to determine the appropriate namespace mapping and
the point of evaluation. How do you determine to correct mapping in context
see AbstractElement.getNamespaceForPrefix, and
DefaultElement.getNamespaceForPrefix
I do not see how this could help?
I was just pointing you to the code that trewalks currently
Regards
Mike Skells
Chief Solutions Architect
ValidSoft Ltd
F: +44 (0) 20 7033 1965
M: +44 (0) 7740 520 717
[EMAIL PROTECTED]<mailto:[EMAIL PROTECTED]>
<http://www.validsoft.com/>www.validsoft.com<http://www.validsoft.com/>
ValidSoft Ltd is a Private Limited Company.
Registered Address:Castle Buildings, Tara Street, Tullamore, Co. Offaly,
Ireland.
Registration Number: 377068 Registered in Dublin.
The information in this e-mail is confidential and may be legally privileged.
It is intended solely for the addressee(s). Access to this e-mail by anyone
else is unauthorised. If you are not the intended recipient, any disclosure,
copying, distribution or any action taken or omitted to be taken in reliance on
it, is prohibited and may be unlawful. When addressed to our clients any
opinions or advice contained in this e-mail are subject to the terms and
conditions expressed in the governing ValidSoft client terms and conditions.
________________________________
From: Marc Pellmann [mailto:[EMAIL PROTECTED]
Sent: 06 November 2008 09:51
To: Mike Skells
Cc: [EMAIL PROTECTED]; dom4j-dev@lists.sourceforge.net
Subject: Re: [dom4j-dev] dom4j extensions
Hi Mike!
Scanning the document in this case is not an option, and as namespaces may be
removed, and content shared within the document, maintaining a map of usage is
not trivial in code, CPU or memory.
I do not want to scan the document to build the list of namespaces. The
add(Namespace) method of AbstractElement could add each new namespace to the
specific new XPathNamespaces object which is declared at the document (in my
addition).
I would suggest that any code that determines namespace could use a namespace
resolution strategy that is appropriate for its needs, and this should be able
to be defaulted without code.
This is what the DefaultNamespaceContext does, albeit without strategy options,
but any progreammer can withthe 1.6.1 implementation provide a different
namespace context, appropriate for their needs, and what you are proposing is
such an alternative I believe
What is needed is a NamespaceContext (but at best not only for jaxen, but that
is an other point) which holds all namespaces that are declared in the
document. And what is needed is code to collect this namespaces in creation of
the document.
The Problem with only add namespaces to the document with add(Namespaces) is in
adding of branches. To solve this there might be
1) a more complex strategy to hold namespace declarations for each branch
2) retrieval of all namespaces from the branch while adding
3) add all namespaces of the document of the branch (if it comes from an other
document), because more namespaces than needed should not be a problem
For me point 3 would be enough.
see AbstractElement.getNamespaceForPrefix, and
DefaultElement.getNamespaceForPrefix
I do not see how this could help?
--
Viele Grüße / best regards
Marc Pellmann (Software Architect)
inubit - integrating your business and IT
inubit AG
Schöneberger Ufer 89-91
D-10785 Berlin
Fon: +49.30. 72 61 12-132
Fax: +49.30. 72 61 12-100
Freecall: 0800-go inubit
Web: www.inubit.com<http://www.inubit.com>
Vorstand: Dr. Torsten Schmale
Vorsitzender des Aufsichtsrates: Dr. Wolf-Dieter Klemt
Registergericht: AG Charlottenburg
Registernummer: HRB 80154
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
dom4j-dev mailing list
dom4j-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dom4j-dev
