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.
Let me clarify. I didn't mean that the document would be ambiguous, I
mean that the means of creating it could be. E.g. take my preferred
syntax, and consider these code snippets:
$root = new SimpleXMLElement(
'<ns1:r xmlns="urn:ns1" xmlns:ns1="urn:ns1" />'
);
$root->addChild("child",null,SIMPLEXML_DEFAULT_UNPREFIXED);
echo $root->asXML();
// Gives: <ns1:r xmlns="urn:ns1" xmlns:ns1="urn:ns1"><child /></ns1:r>
$root = new SimpleXMLElement(
'<ns1:r xmlns:ns1="urn:ns1" />'
);
$root->addChild("child",null,SIMPLEXML_DEFAULT_UNPREFIXED);
echo $root->asXML();
// Gives: <ns1:r xmlns:ns1="urn:ns1"><child /></ns1:r>
In the first case, the child is in urn:ns1, in the second case, it is
not. So, at the time of the addChild() call, you don't actually know
what namespace your element will end up in.
And if you *want* that distinction not to matter, it is a violation of
the XML namespace spec, which says that conforming documents must be
interpreted according to namespace defaulting rules, element names must
always be considered qualified, etc..
So, either there is ambiguity while you are creating the document, or
there is violation of the spec.
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
Sorry; I was unclear (again). By '-1 for using "unqualified"' I meant 'a
vote against using "unqualified"'.
I don't think you should just use an int, but should provide a constant
that evaluates to it, so more readable code can be written:
$sxe->addChild('child', 123, SIMPLEXML_DEFAULT_UNPREFIXED);
instead of
$sxe->addChild('child', 123, -1);
I think using 0 or 1 would be better than -1, i.e. make it like an enum
or a bitmask so it can be extended in future if ever necessary
(unlikely, but best to be prepared!).
That wouldn't be hard to do. But I don't really want to create a patch, unless
someone will accept it.
I'd be happy with the above as long as you add a constant, but like you,
I am a mere mortal so have no power to approve/reject/commit/etc..
I believe Rob Richards, who wrote back briefly before, is the right man
to give approval to this (CCing him directly).
I'll butt out now, I think.
Cheers,
Ben.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
