Re: [PHP-DEV] PHP's mail servers suck

[Tom Samplonius]

> On Oct 25, 2017, at 2:17 PM, Aidan Woods  wrote:
> 
>> anyways, don't reject mailing-list messages
> 
> I don't reject the messages, Google rejects the messages because of failed
> DMARC requirements. See support[.]google[.]com/mail/answer/2451690
> 
> The error occurs when the php mailing list attempts to forward messages
> from a domain which has a (likey strict) DMARC policy, and sends emails as
> if it was the sender from the domain holding that policy.
> 
> In any case, despite failed delivery due to the policy being an issue – it
> would be great if I wouldn't be unsubscribed from the mailing list because
> of an error that has nothing to do with me 路‍♂️

  I’m using GSuite for email, and I’ve never received a warning from the 
php.net mail system that mail was bouncing anytime in the past two years, nor 
have I been automatically unsubscribed.  

  That said, email is a lot harder than it looks.


Tom

smime.p7s
Description: S/MIME cryptographic signature

Re: [PHP-DEV] Move internals discussion to a better medium

[Tom Samplonius]

 On Aug 4, 2015, at 12:12 PM, Lester Caine les...@lsces.co.uk wrote:
 
 On 04/08/15 17:12, Terry Cullen wrote:
 Redmine would be a good option.  http://www.redmine.org/
 
 The feature list has most everything covered in this thread.
 http://www.redmine.org/projects/redmine/wiki/Features
 
 Feature list is nice, but is PHP really unable to provide a similar service?

I think anyone suggesting Redmine is trolling this list.

The question was about forum software and Redmine has no specific forum 
support.  And if you wanted a dev tracker tool, which Redmine is, Phabricator 
is obviously superior and more modern than Redmine which is just a Trac clone.  
Phabricator is opinionated about process, which is a barrier for those who 
prefer existing processes.  But neither really address what this thread is 
about.

 -- 
 Lester Caine - G8HFL
 -
 Contact - http://lsces.co.uk/wiki/?page=contact
 L.S.Caine Electronic Services - http://lsces.co.uk
 EnquirySolve - http://enquirysolve.com/
 Model Engineers Digital Workshop - http://medw.co.uk
 Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
 
 -- 
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php
 

Tom
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] PDO Extension contributions

[Tom Samplonius]

On 2013-05-01, at 6:28 AM, Guilherme Capilé wrote:

 Ola Ferenc,
 
 I'm willing to resurrect the development, how can I do it? Right now
 I'm having trouble in making a simple patch applied...
 
...

  I support that.  When someone has patches to commit, I don't think the 
attitude should be ...if we could (either) resurrect the development  
Someone is trying to do that!  PHP development needs to get better about 
on-boarding new developers.  I've submitted a patch to the docs before, and it 
took months to be applied.  This type of experience actively discourages new 
developers.  And the PHP dev mailing list is filled with if only someone would 
submit patches comments from the current developers.

  One of the current PHP developers should spend some time spotting valuable 
patches, and helpful new contributors, because if all they do is bring onboard 
5 new developers per year, that will accomplish more for PHP than any code they 
themselves could write.

  I think the PDO_DBLIB is important.  I use it, and I've just switched jobs, 
and found that they use it all over the place too.  I was surprised to learn 
that it is broken or nearly broken in 5.4.  And we use it for Sybase too.


Tom
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] 5.4 moving forward

[Tom Samplonius]

 Currently - A lot of ISP's are 'stuck' with PHP5.2 or earlier simply

  I don't know if this is really the case.  I work in this industry, and most 
of the small to mid hosting company's use cPanel or Plesk, and both include PHP 
5.3.  I've personally seen very few issues moving from older PHP 5.x versions 
to PHP 5.3 (over about 2,000 sites, mainly small business sites).  And Plesk 
and cPanel do not appear to have perpetual licenses available anymore, so ISPs 
that use these products are basically forced to update at minimum once a year, 
when their license expires.  I guess they could still technically skip 
upgrades, when they are prompted, but major updates are available to them.

  A real issue is RHEL (and CentOS).  RHEL locks the PHP major version to 
whatever it is when they release their major version.  But they also maintain 
their own patches, and release their own updates, which slightly makes up for 
it.  So RHEL6 will have whatever PHP that was around, then, which I hope is PHP 
5.3 (I don't have any RHEL6 servers yet).  So RHEL6 will always be PHP5.3.x 
based.

  But the update pipeline is still a few months, so it is important that each 
release is a good release.  Plus, don't worry about the Non-Updating ISP.  That 
is less of an issue that it once was.  


Tom

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Fwd: What's up with Quercus?

[Tom Samplonius]

...
 Running PHP on the JVM doesn't mean making PHP more like Java. It
 just means running the PHP language on a platform with a lot of
 benefits and advantages, and given the differences in engineering
 resources dedicated to each, one that's likely to continue to
 improve a lot faster than the native PHP runtime.

  I think you are assuming that the bit of code that converts PHP to JVM 
bytecode (and/or a Java PHP interpreter) is an insignificant chunk of 
engineering.  Quercus has lagged PHP5 development, and it needs work in order 
to run common apps.  Plus, an analog of the Ruby RSpec project will probably 
have to be built for PHP (PHPSpec?).  The PHP5 implementation is the spec right 
now, just like Ruby (used to be).

  Quercus is currently a component of a commercial Java application server.  
Can Quercus can be run in another app server, like Jetty, or does it only work 
in Resin?  I doubt that Caucho would be interesting in making Quercus work 
stand alone. Quercus will probably need to be forked.

  That is quite a lot of work.  How many people did it take to create JRuby 
(Ruby on the JVM) and the RSpec project?  From the mailing list, it looks like 
it was about 5 to 8 core developers over about 2 years.  And then after all 
that, JRuby is still not the preferred deployment environment for Ruby (it's 
mod_rails aka Passenger).  Though, RSpec did end up making the original Ruby 
implementation better.

  I'm not opposed to PHP on the JVM, but it is not a small undertaking.  You 
should probably begin by extracting the Quercus code from from the Caucho 
subversion repository, and import it into a new github repository, and then see 
if you can get Quercus to run without Resin.


 As far as HipHop, from what I've seen it holds zero interest for me
 right now. If you're FaceBook, and you're spending hundreds of
 millions of dollars on servers every year then squeezing 5% or 10%

  More like 50% to 100%.


 more performance out of you code is probably worthwhile. But with
 only a few hundred servers running the PHP applications I'm
 responsible for, I'm much more interested in developing less-buggy
 applications faster, leveraging other people's frameworks instead of

  PHP has shed loads of web frameworks too. 


 reinventing the wheel (hence my interest in Java), improving
 monitoring and deployment, etc.

 -- Arnold


Tom

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Unicode (was What's up with Quercus?)

[Tom Samplonius]

  The presentation implied that there was vast goals for the project,
  including a lot of localization features. It seems like some of the
  smaller features can be worked into a Son-of-Unicode project, and
  maybe rolled into 5.5?
 
 it would be a good thing, but nobody stepped up for that, and it
 seems that somehow it isn't really important for the internals.

  This happens in every open source project.  You can't expect a group of open 
source developers to develop what you ask for.  So, it isn't the fault of 
internals that no one is stepping up.  Go onto any open source developers 
mailing list, and send a You guys should do X, and you'll see the exact same 
thing happen.

  On top of that, where is no concept for what Unicode-for-PHP should be.  
There was for the previous (now deemed to have failed) project, including 
UTF16.  But should it be UTF16 or UTF8 or should both be supported?  Unicode 
identifiers...yes or no?  I'm quite interested what everyone's Unicode wishlist 
would look like.


  But right now, there is this impression of failure, and implication
  that PHP has no Unicode, because a project to add UTF16 to
  everything in PHP wasn't completed.

 yes there is the impression, Unicode support was the flagship feature
 of the PHP6 release.

  Actually, for me, the deprecated features were far more important than 
Unicode, as I can create Unicode web apps right now.  The PHP Wikipedia page is 
wrong about this too, and states that addslashes() can be used instead of magic 
quotes.  addslashes() should probably be deprecated too (and it isn't Unicode 
aware either, so removing it solves two problems).


 of course we can rationalize the importance of the full unicode
 support, or redefine success, but that won't change the facts that 5
 years of work on I18n was botched with PHP6.

  Five years, without a being able to release even a single minimally 
implemented feature, is definitely a lesson learned.  If you have been coding 
for a year, and there isn't anything that you can release, you need to make 
radical changes to what you've been doing.

 Tyrael

Tom

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Unicode (was What's up with Quercus?)

[Tom Samplonius]

  The PHP Wikipedia page is wrong about this too, and states that
  addslashes() can be used instead of magic quotes. addslashes()
  should probably be deprecated too (and it isn't Unicode aware
  either, so removing it solves two problems).
 
 magic_quotes did the same thing than manually addslashing every
 argument AFAIK, so I can't see why you say they couldn't be used
 interchangeably.
 the problem with magic was the magic part, addslashes is a valid
 feature on its own.

 It is not that magic_quotes and addslashes() can't be used interchangeably, it 
is that addslashes() shouldn't be used either.  addslashes() isn't aware of 
other characters sets, so it won't add slashes to everything it should.  It 
works fine for ASCII, but will probably open up a security hole when used on 
UTF8 strings.  Even the addslashes() manual page, highly recommends you don't 
use addslashes().

  Ideally, addslashes() should be added to the deprecation list too.  It will 
have to be removed (or somehow fixed) as part of Full Unicode support anyways.

  That is why I think the deprecation of features for PHP6 was more important 
than Unicode.  It makes PHP6 secure (well, more secure) by default.


 Tyrael


Tom

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Unicode (was What's up with Quercus?)

[Tom Samplonius]

  How has Unicode been lost?

 http://www.slideshare.net/andreizm/the-good-the-bad-and-the-ugly-what-happened-to-unicode-and-php-6

  Well, that explains how that particular project melted down, but what Unicode 
features did people want out of that project that they didn't get?  The 
presentation implied that there was vast goals for the project, including a lot 
of localization features.  It seems like some of the smaller features can be 
worked into a Son-of-Unicode project, and maybe rolled into 5.5?  

  But right now, there is this impression of failure, and implication that PHP 
has no Unicode, because a project to add UTF16 to everything in PHP wasn't 
completed.  


Tom

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Unicode (was What's up with Quercus?)

[Tom Samplonius]

 With the loss of Unicode (which now lacks even an implementation
 plan)
...

How has Unicode been lost?  There is tons of encoding stuff in PHP.  As of 5.3, 
you can use declare() to set the encoding for scripts.  There is the mb_* stuff 
for multibyte support.  Obviously, saying PHP has no Unicode as others have 
said, is wrong.  There is definitely some Unicode in PHP.

Unicode (which itself is changing), will probably never be done, and 
therefore never done in PHP.  But I've worked on multilingual UTF8 web apps in 
PHP, and I never lacked for support.  Maybe sorting of Unicode strings?  And I 
guess that some of the PHP string functions can be confused on some mb strings.


Tom

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Fwd: What's up with Quercus?

[Tom Samplonius]

 I sent this message to the php-general list, but haven't gotten any
 replies. Looking at the archives for the two lists, I realized that
 I'm probably much more likely to get informed responses from this
 list than the general list:

  Probably a Caucho list would better.  php-internals is primarily focused on C 
PHP implementation (sometimes called mod_php, but can be run well in other 
modes and other APIs now) of PHP.

...
 and enthusiastic about it. The cancellation of PHP 6 combined with
 the steady trickle of PHP-related bugs and security vulnerabilities
 that have become public over the past few years had made me very
 nervous about the future of the platform. Having an open-source
...

  That is actually quite normal.  Bug reports, some of which are security 
related, and then the release of new point releases are part of the normal 
heartbeat of software development.  When the heart stops beating, the product 
is dead.

  And so far as PHP6... a lot of the features that were supposed to be in PHP6 
actually ended up in 5.3.  So rather than canceled, no longer necessary 
might be a better description of what happened to PHP6.

 Although I've had great results so far in my experiments with
 Quercus, I'm curious to hear about other PHP developers' experiences
...

  Since Quercus is basically the same speed as PHP+APC, but doesn't support all 
of the extensions that PHP5.3, it has no interest for me.  It probably is only 
useful for those with some Java libraries they have to access from PHP5.  But 
the popular solution to that, these days is use some sort of REST or Thrift 
interface to the Java library.

  Plus, Cauch doesn't state which version of PHP5 they are compatible with.  
PHP5.2?  PHP5.3?  There are new language features in 5.3.

  Also, HipHop is getting pretty good too.  Since HipHop is faster than 
PHP+APC, it would be faster than Quercus as well.  Drupal works quite well 
under HipHop, apparently (see 
http://php.webtutor.pl/en/2011/05/17/drupal-hiphop-for-php-vs-apc-benchmark/).


Tom

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Making SimpleXML more useful

[Tom Samplonius]

 While I think this would make SimpleXML more stupid, not less, as it
 seems
 braindead to me to allow users to create documents ambiguously and/or
 which
 essentially violate the XML namespace spec, I think the way to do

  Allowing child elements to be unqualified is neither braindead or ambiguous.  
All standalone XML documents are ambiguous, because XML is just structured 
information without a definition of the structure (let alone the semantics of 
the information).  XMLSchemas precisely define the structure, including 
allowable elements, child elements, quantities of elements and data types.  And 
if that schema includes the attribute 'elementFormDefault=unqualified', then 
child elements have to be unqualified.  And that is certainly strictly 
specified, unlike a schemaless XML.

  In fact, it would save a lot of time, if SimpleXML had a schema mode, and 
could validate and parse XML based on a provided schema.  XMLReader has 
validation support, but it doesn't use the schema for binding XML elements to a 
data structure.

 this would be to
 define a magic constant and use that. E.g.

 const SIMPLEXML_DEFAULT_UNPREFIXED = 0

 I used 'default unprefixed' to better describe what is going to
 happen in terms of
 namespaces (as within the context of a namespaced document is the
 only time this
 would be needed): the element is going to be created in the default
 namespace by
 virtue of being unprefixed. This highlights to the user the ambiguity
 involved (it
 is not necessarily known what the default namespace is at any point),
 as well as
 the 'priority' the XML generation will take at that point (of adding
 an unprefixed
 element).

 -1 for using unqualified; whatever is used should not be a possibly
 valid
 namespace name.

  Well, it is possible to examine the type, so (int) -1 is distinct from -1, 
so there is no risk of considering it an actual namespace.  So, like this:

$sxe-addChild('child', 123);  # Adds element with namespace inherited from the 
parent
$sxe-addChild('child', 123, 'urn:somenamespace'); # Adds child with specified 
namespace
$sxe-addChild('child', 123, -1);  # Adds child with no namespace qualification


That wouldn't be hard to do.  But I don't really want to create a patch, unless 
someone will accept it.


 Ben.


Tom

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Making SimpleXML more useful

[Tom Samplonius]

  $sxe-addChild('child', 123); # Adds element with namespace
  inherited from the parent
  $sxe-addChild('child', 123, 'urn:somenamespace'); # Adds child
  with specified namespace
  $sxe-addChild('child', 123, -1); # Adds child with no namespace
  qualification

 Again, there is no problem here as child xmlns=123/child is
 unqualified

  Specifying the xmlns pseudo-attribute *is* namespace qualification.  
Qualification is the act of specifying a namespace.  And there is a difference 
between no namespace (xmlns=) and the default namespace.  The XML document:

parent xmlns=urn:something
 child xmlns=123/child
/parent

and:

parent xmlns=urn:something
 child123/child
/parent

are different documents.  In the first case, the child element is not in any 
namespace, and in the later, the child element is in the default namespace.  
Ben Schmidt mentioned this in an earlier response.

  XMLSchema's can further specify the structure of XML documents beyond what is 
in the XMLNamespace spec, including requiring that elements be unqualified and 
specifying a target namespace for the unqualified elements.  An XML document 
structure defined by an XMLSchema really only has one correct form.  


Tom

  

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Making SimpleXML more useful

[Tom Samplonius]

 That patch is not a good idea. 
 
 Assume you have this situation: 
 
 foo xmlns=urn:lol 
 x:bar xmlns:x=urn:hai 
 /x:bar 
 /foo 
 
 Adding a child baz to bar and have it default to no namespace 

Actually, my patch wouldn't change the default action of addChild(). It would 
still inherit the namespace qualification of the parent by default. 

 prefix would result in this: 
 
 foo xmlns=urn:lol 
 x:bar xmlns:x=urn:hai 
 baz / 
 /x:bar 
 /foo 
 
 Now baz / would be in the namespace urn:lol. 

I don't see why this is a problem? I actually need to be able to add 
unqualified child elements. 

 Keep in mind that xmlns= is, as per the XML spec, a perfectly valid 
 way to reset the namespace of an element. 

Right now, the behavior of addChild() is: 

* $namespace is unspecified -- inherit from parent 
* $namespace is specified -- use that as the namespace for the element (and 
this could be )

I need a third option, where I can add an element that is unqualified. There 
really are just two possible choices, either add a new value of $namespace 
(like (int) 0) that requests this behavior. Or, use some sort of magic 
namespace value (like unqualified) to specify an unqualified element.

Is there any opinion on which is better for addChild()?

...
 SimpleXML is supposed to be simple (I find it more stupid than simple, but 
 that's my personal opinion).
 I guess that's why it, by default, inherits the parent namespace

The only way to make it less stupid, is to start fixing it.  


Tom 

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Making SimpleXML more useful

[Tom Samplonius]

- Original Message - 

 Looking at this in more detail...I don't think there's a bug here, or
 a
 patch required.

...
  problem for me, as I have an XML schema that specifies that the
  child
  elements must not namespace qualified.

 Is this possible in an XML schema? I don't know much about schemas,
 but
...

  Absolutely, if the XML schema has the elementFormDefault attribute set to 
unqualified, the child elements must be unqualified.


 I would also expect, if the child were to be namespaced, that these
 are
 equivalent:

 ns1:parent xmlns=whatever xmlns:ns1=whatever
 childabc/child
 /ns1:parent

 ns1:parent xmlns:ns1=whatever
 ns1:childabc/ns1:child
 /ns1:parent
...

  In the first case, the child element is unqualified, and in the second, it 
is not.  They are not the same thing, either semantically or otherwise.


 and the xmlns= is necessary. If this functionality were removed,
 how
 could this be done?

  For what?  In the spec (http://www.w3.org/TR/xml-names/#iri-use), it says:

The empty string, though it is a legal URI reference, cannot be used as a 
namespace name. 


 Sure, SimpleXML could perhaps output XML that is slightly more
 efficient/less verbose than it currently does, but its output is not
 incorrect, and the functionality you want to remove is necessary in
 other circumstances.

  I don't see how removing the ability to use  as a namespace is an issue, 
since  can't be used as a namespace name.


 Ben.

Tom

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

[PHP-DEV] Making SimpleXML more useful

[Tom Samplonius]

  It is not possible to use SimpleXML to add a child element without a 
namespace prefix to a parent element that has a namespace element. Instead, the 
child element inherits the namespace prefix of the parent. So this XML 
fragment: 

ns1:parent 
childabc/child 
/ns1:parent 

is impossible to construct with SimpleXML. The SimpleXML extension would add 
the child element with the ns1 namespace prefix. This is a problem for me, as 
I have an XML schema that specifies that the child elements must not namespace 
qualified. 

  I looked into the SimpleXML code, and I believe this is actually a bug, as 
the code goes through some effort to distinguish between a set but blank 
namespace, and a set but not blank namespace. I believe the design intent was 
that specifying a blank namespace, would mean that no namespace would be used, 
rather than inheriting the namespace of the parent. 

?php 
header('Content-Type: text/plain'); 

$r = new SimpleXMLElement('r /'); 
$c1 = $r-addChild('ns1:child1', NULL, 'urn:myspace1'); 
$c1-addChild('child2'); 
echo $r-asXML(), \n; 

$r = new SimpleXMLElement('r /'); 
$r-addChild('Thing1', 100, ''); 
echo $r-asXML(), \n; 


Expected result: 
 
?xml version=1.0? 
rns1:child1 xmlns:ns1=urn:myspace1ns1:child2//ns1:child1/r 

?xml version=1.0? 
rThing1100/Thing1/r 

Actual result: 
-- 
?xml version=1.0? 
rns1:child1 xmlns:ns1=urn:myspace1ns1:child2//ns1:child1/r 

?xml version=1.0? 
rThing1 xmlns=100/Thing1/r 


  The current behavior of specifying a blank namespace, is to add a literal 
blank namespace (xmlns=), which isn't a useful result. No one would be 
depending on using a blank namepspace to get xmlns=. 

The patch is pretty simple: 

--- simplexml.c.orig 2011-04-26 16:00:31.0 -0700 
+++ simplexml.c 2011-04-26 16:00:41.0 -0700 
@@ -1619,12 +1619,14 @@ 
localname = xmlStrdup((xmlChar *)qname); 
} 

+ /* Add new child with no namespace */ 
newnode = xmlNewChild(node, NULL, localname, (xmlChar *)value); 

if (nsuri != NULL) { 
+ /* If namespace is not NULL but blank, use no namespace 
+ Use this to prevent inheriting the name space of the parent */ 
if (nsuri_len == 0) { 
newnode-ns = NULL; 
- nsptr = xmlNewNs(newnode, (xmlChar *)nsuri, prefix); 
} else { 
nsptr = xmlSearchNsByHref(node-doc, node, (xmlChar *)nsuri); 
if (nsptr == NULL) { 


(see also http://bugs.php.net/bug.php?id=54354) 


If this patch is accepted, I'll also submit patches to clarify the 
documentation and add some tests. SimpleXML with the above patch, passes the 
existing tests. It is hard to know for sure what the design intent was, as the 
code has few comments, few tests, and the documentation is pretty thin. But I 
believe the above is correct. 


Tom 

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Making SimpleXML more useful

[Tom Samplonius]

- Original Message - 

 A similar problem regarding attributes, that got classified as a doc
 bug, but I
 don't think is one: http://bugs.php.net/42083

 If you're fishing around that area of the code, though, perhaps it is
 quite
 obvious to you where/how a patch should be made?

  I would recommend that you re-test that in 5.3.6, as there were a few 
changes.  I don't know what they were specifically, as I never looked at the 
5.2 SimpleXML code.

  But I also see one issue with your example.

You look for all child elements in namespace 'http://localhost/a' as follows:

foreach ($xml-children('http://localhost/a') as $elem) {
unset($elem['attr']);
$elem['attr']=new;
$elem['attr']=three;
echo $elem['attr'].\n;
}

I would expect the children() method to return just the last two elements of 
your input XML:

root xmlns=http://localhost/a; xmlns:ns=http://localhost/a;
elem attr=abc/
elem ns:attr=abc/
ns:elem attr=abc/
ns:elem ns:attr=abc/
/root

as the last two elements are the only ones in the 'http://localhost/a' 
namespace.


  But this might be affected by the fact that you specified a namespace on the 
constructor.  I'm not entirely sure what specifying a namespace on the 
constructor does, but I feel it is best avoided (and it isn't described in the 
docs).  So rather than:

$xml = simplexml_load_string($str,'SimpleXMLElement',0,'http://localhost/a');

just:

$xml = simplexml_load_string($str);



Tom


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php