You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@mina.apache.org by Bernd Fondermann <bf...@brainlounge.de> on 2010/05/09 20:23:49 UTC
[Vysper] XML Namespaces [WAS: Re: Moving new nbxml in trunk]
Niklas Gustavsson wrote:
> On Wed, May 5, 2010 at 7:55 PM, Bernd Fondermann
> <be...@googlemail.com> wrote:
>> The group chat problem is between Psi and Psi. But I didn't test that
>> today, but will tomorrow.
>
> Great, let me know the results (or how to reproduce it).
>
>> And I don't think those xmlns="" should be there. Isn't this kind of
>> overwriting the default namespace, when you really want the default
>> namespace from the outer element to propagate?
>
> Right, it sets the default namespace to be the empty namespace. This
> is normally due to us not setting the correct namespace when creating
> elements. See rev 941337 for an example of fixing this problem.
But this is quite awkward, isn't it?
I don't want to re-set the namespace on all inner elements. This will
lead to errors (copy/paste, missing) and is much more work than neccessary.
What I wanted to achieve with the initial implementation, is that
namespaces get propagated automatically within the scope. That's also my
notion of how XML default namespaces are scoped and what the patch is
solving.
I see now why you don't consider the patch to be a fix, at least in
cases of nsAttr.getValue eq "".
For nsAttr.getValue == null I'm definitively pro not rendering xmlns="".
So my resultion would be:
+ propagating default namespaces to inner elements is implicit. (means:
possible reverting revision 941337, which is an strange revision number
anyway ;-)
+ setting the default namespace to "" means overriding the outer scope's
default ns. this must be done explicitely.
+ empty default namespaces get rendered as xmlns="".
WDYT?
Bernd
Re: [Vysper] XML Namespaces [WAS: Re: Moving new nbxml in trunk]
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Tue, May 11, 2010 at 3:55 PM, Bernd Fondermann
<be...@googlemail.com> wrote:
> The only thing which nags me is that the current trunk has the
> xmlns="" issue, my patch makes the problem go away, but it is not a
> fix.
How do I reproduce this issue so that I can look into fixing it?
/niklas
Re: [Vysper] XML Namespaces [WAS: Re: Moving new nbxml in trunk]
Posted by Bernd Fondermann <be...@googlemail.com>.
On Tue, May 11, 2010 at 13:21, Niklas Gustavsson <ni...@protocol7.com> wrote:
> On Mon, May 10, 2010 at 5:56 PM, Bernd Fondermann
> <be...@googlemail.com> wrote:
>> Is there some solution we could base consensus on?
>
> Since it's a question of either explicitly declaring namespaces or
> explicitly not doing so (to reduce cluttering if I've understood you
> correctly), there seems to be hard to find a common ground. I would
> like to propose two different ways forward. Either, get input from the
> greater community, this decision is not really down to only us two.
> Perhaps as a vote. Or, and this would be my preferred option at this
> time, give this change some further time. The change has only been in
> trunk for a few days and very limited development has occurred since.
> Thus, I'm not sure we have yet evaluated (used in anger) the changes
> sufficiently to dismiss them. If you or others still don't find any
> value in declaring namespaces and find them annoying then, let's
> discuss further or call a vote at that time.
Agreed. This is good.
The only thing which nags me is that the current trunk has the
xmlns="" issue, my patch makes the problem go away, but it is not a
fix.
Bernd
Re: [Vysper] XML Namespaces [WAS: Re: Moving new nbxml in trunk]
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Mon, May 10, 2010 at 5:56 PM, Bernd Fondermann
<be...@googlemail.com> wrote:
> Is there some solution we could base consensus on?
Since it's a question of either explicitly declaring namespaces or
explicitly not doing so (to reduce cluttering if I've understood you
correctly), there seems to be hard to find a common ground. I would
like to propose two different ways forward. Either, get input from the
greater community, this decision is not really down to only us two.
Perhaps as a vote. Or, and this would be my preferred option at this
time, give this change some further time. The change has only been in
trunk for a few days and very limited development has occurred since.
Thus, I'm not sure we have yet evaluated (used in anger) the changes
sufficiently to dismiss them. If you or others still don't find any
value in declaring namespaces and find them annoying then, let's
discuss further or call a vote at that time.
/niklas
Re: [Vysper] XML Namespaces [WAS: Re: Moving new nbxml in trunk]
Posted by Bernd Fondermann <be...@googlemail.com>.
On Mon, May 10, 2010 at 17:40, Niklas Gustavsson <ni...@protocol7.com> wrote:
> On Mon, May 10, 2010 at 4:10 PM, Bernd Fondermann <bf...@brainlounge.de> wrote:
>> Well, if <item> has the same semantic in all cases, this would be perfect.
>> If it carries different semantics for both #user and #admin, you'd have
>> different signatures for the method anyway, to propagate these semantics.
>
> Sorry, I probably did not make my example as clear as I've could have.
> The example only serves to illustrate how we would have to backtrack
> in what context an element is created, that it might not show
> immediately where I create an element what type (the namespace URI is
> as important as the local name in the identity of an element) the
> element is.
>
>> So basically, you're proposing to design an API which requires saying:
>> * I want to use ns 'http:123' on element 'iq'
>> * I still want to use ns 'http:123' on inner element 'query'
>> * I still want to use ns 'http:123' on inner element 'items'
>> * Yes, I still want to use ns 'http:123' on inner element 'item', really!
>
> Yes, that's correct.
>
>> which is redundant.
>
> An explicit. I would think this comes down to a matter of taste, which
> of course differs.
>
>> And you justify this by emphasizing that everybody
>> else does which is ok from an XML parser PoV, but not so much from a
>> Vysper PoV.
>
> I'm not sure where I see the Vysper XML API would need to differ from
> any other XML API, as the perform the exact same task.
>
>> Why? Because the impact of implementing this would be:
>> * Changing a lot of working code, potentially introducing bugs, without
>> adding any information which isn't already there.
>
> I believe this is now complete, but like you say, there might have
> been regressions introduced as in any significant change. In this
> change, from my point of view (or perhaps matter of taste), we added
> lots of information of what elements we're actually creating. I no
> longer have to extrapolate this from the context (something my
> admittedly limited brainpower tends to find hard).
>
>> * Making stanza creation much more verbose, cluttering namespaces all
>> over the place.
>
> Cluttering for you, making it clear for me.
>
>> * Tracking everywhere if a stream is c2s or s2s, to appropriately be
>> able to add xmlns='jabber:client' vs. xmlns='jabber:server'
>
> Right, again, this makes it clear in what case an element must be used.
>
>> I don't want to go through all this.
>>
>> If the renderer/writer is intelligent enough to derive the ns, then
>> please let's follow "DRY", regardless of other APIs.
>
> To me, this is not a case of having clever code (which we do and did).
> It's a matter of having clear and (while I don't really like this
> term) self-documenting code.
>
>> XMPP doesn't need a full blown XML parser.
>
> Right, nor do we have one. We currently support the exact XMPP subset
> with one configurable addition, comments. Personally I don't intent to
> write a fully compliant XML API, the DTD stuff in particular does not
> seem very useful for me in the streaming case, but since the current
> API is reusable in other contexts, others might have different views
> on this.
>
>> So I can see basically two
>> options:
>> 1. Introduce (aka. keep) ways to make the renderer intelligent enough
>> (well, effectively make the API intelligent enough).
>> 2. Rollback Vysper to it's own, buggy-but-sufficient XML handling code.
>
> The current API is my best effort of producing an XML API which I find
> straight-forward and attempting to follow the principle of least
> astonishment. And that I think will be most familiar for other
> developers. But, this is merely judged from my limited point of view,
> and taste will differ.
ok. we have a draw here. how do we go on?
I don't want to -1 anything, it's simply not worth it.
Is there some solution we could base consensus on?
Bernd
Re: [Vysper] XML Namespaces [WAS: Re: Moving new nbxml in trunk]
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Sun, May 9, 2010 at 10:19 PM, Niklas Gustavsson <ni...@protocol7.com> wrote:
...
> where the parent <x> element is created and see what namespace that is
Sorry, that should have been <query> element. I'm too tired :-)
/niklas
Re: [Vysper] XML Namespaces [WAS: Re: Moving new nbxml in trunk]
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Mon, May 10, 2010 at 4:10 PM, Bernd Fondermann <bf...@brainlounge.de> wrote:
> Well, if <item> has the same semantic in all cases, this would be perfect.
> If it carries different semantics for both #user and #admin, you'd have
> different signatures for the method anyway, to propagate these semantics.
Sorry, I probably did not make my example as clear as I've could have.
The example only serves to illustrate how we would have to backtrack
in what context an element is created, that it might not show
immediately where I create an element what type (the namespace URI is
as important as the local name in the identity of an element) the
element is.
> So basically, you're proposing to design an API which requires saying:
> * I want to use ns 'http:123' on element 'iq'
> * I still want to use ns 'http:123' on inner element 'query'
> * I still want to use ns 'http:123' on inner element 'items'
> * Yes, I still want to use ns 'http:123' on inner element 'item', really!
Yes, that's correct.
> which is redundant.
An explicit. I would think this comes down to a matter of taste, which
of course differs.
> And you justify this by emphasizing that everybody
> else does which is ok from an XML parser PoV, but not so much from a
> Vysper PoV.
I'm not sure where I see the Vysper XML API would need to differ from
any other XML API, as the perform the exact same task.
> Why? Because the impact of implementing this would be:
> * Changing a lot of working code, potentially introducing bugs, without
> adding any information which isn't already there.
I believe this is now complete, but like you say, there might have
been regressions introduced as in any significant change. In this
change, from my point of view (or perhaps matter of taste), we added
lots of information of what elements we're actually creating. I no
longer have to extrapolate this from the context (something my
admittedly limited brainpower tends to find hard).
> * Making stanza creation much more verbose, cluttering namespaces all
> over the place.
Cluttering for you, making it clear for me.
> * Tracking everywhere if a stream is c2s or s2s, to appropriately be
> able to add xmlns='jabber:client' vs. xmlns='jabber:server'
Right, again, this makes it clear in what case an element must be used.
> I don't want to go through all this.
>
> If the renderer/writer is intelligent enough to derive the ns, then
> please let's follow "DRY", regardless of other APIs.
To me, this is not a case of having clever code (which we do and did).
It's a matter of having clear and (while I don't really like this
term) self-documenting code.
> XMPP doesn't need a full blown XML parser.
Right, nor do we have one. We currently support the exact XMPP subset
with one configurable addition, comments. Personally I don't intent to
write a fully compliant XML API, the DTD stuff in particular does not
seem very useful for me in the streaming case, but since the current
API is reusable in other contexts, others might have different views
on this.
> So I can see basically two
> options:
> 1. Introduce (aka. keep) ways to make the renderer intelligent enough
> (well, effectively make the API intelligent enough).
> 2. Rollback Vysper to it's own, buggy-but-sufficient XML handling code.
The current API is my best effort of producing an XML API which I find
straight-forward and attempting to follow the principle of least
astonishment. And that I think will be most familiar for other
developers. But, this is merely judged from my limited point of view,
and taste will differ.
/niklas
Re: [Vysper] XML Namespaces [WAS: Re: Moving new nbxml in trunk]
Posted by Bernd Fondermann <bf...@brainlounge.de>.
Niklas Gustavsson wrote:
> On Sun, May 9, 2010 at 9:52 PM, Bernd Fondermann <bf...@brainlounge.de> wrote:
>> This example is especially appropriate, as it includes beer:
>
> We like that of course :-)
>
>> <?xml version='1.0'?>
>> <Beers>
>> <!-- the default namespace inside tables is that of HTML -->
>> <table xmlns='http://www.w3.org/1999/xhtml'>
>> <th><td>Name</td><td>Origin</td><td>Description</td></th>
>> <tr>
>> <!-- no default namespace inside table cells -->
>> <td><brandName xmlns="">Huntsman</brandName></td>
>> <td><origin xmlns="">Bath, UK</origin></td>
>> <td>
>> <details xmlns=""><class>Bitter</class><hop>Fuggles</hop>
>> <pro>Wonderful hop, light alcohol, good summer beer</pro>
>> <con>Fragile; excessive variance pub to pub</con>
>> </details>
>> </td>
>> </tr>
>> </table>
>> </Beers>
>>
>> Now, I'd like to have an API like this:
>> builder.add("table", "http://www.w3.org/1999/xhtml").
>> add("th").
>> add("tf").
>> addText("Name") ...
>>
>> and *not*
>> builder.add("table", "http://www.w3.org/1999/xhtml").
>> add("th", "http://www.w3.org/1999/xhtml").
>> add("tf", "http://www.w3.org/1999/xhtml").
>> addText("Name") ...
>>
>> while you'd like it the other way round, right?
>
> Yes (of course, you would likely use a constant rather than a string,
> but that's besides the point here).
>
>> Reason for my position: This is straihtforward. You don't redefine java
>> variables when a new scope opens. You'd just redefine them to
>> shadow/override the outer scoped variable.
>> The inner XML elements are not arbitrary. Within a table, you'd expect
>> td, tr etc. to occur. No need to redefine the namespace.
>> However, if non-table elements occur, the namespace gets reset explicitly.
>
> I'm not sure I follow along perfectly well here. But, I'll attempt to
> give an example of why I think inheriting the namespace in the XML
> creation step would be confusing. Let's take the following function
> that creates <item> elements in a MUC implementation:
>
> private XMLElement createItem(XMLElementBuilder builder) {
> builder.startInnerElement("item");
> ...
> }
>
> Now, in MUC, <item> elements can be contained both in the
> http://jabber.org/protocol/muc#user and
> http://jabber.org/protocol/muc#admin namespaces. Which one would this
> be in? To find out, I would have to backtrack to code to find out
> where the parent <x> element is created and see what namespace that is
> in.
Well, if <item> has the same semantic in all cases, this would be perfect.
If it carries different semantics for both #user and #admin, you'd have
different signatures for the method anyway, to propagate these semantics.
> I would rather prefer the namespace be explicit.
>
>> And I don't think you can get rid of looking up outer namespaces in any
>> serious implementation. In the second example, where every add() has an
>> explicit namespace declaration, one would
>> * either repeatedly render the declared xmlns on every element, no
>> tracking of outer ns needed
>> * or, not repeat rendering the declared xmlns, (like *all* XML examples
>> I've seen so far) which can only be achieved by keeping track of what
>> the current namespace is.
>>
>> I don't think XML like this:
>> <table xmlns='http://www.w3.org/1999/xhtml'>
>> <th xmlns='http://www.w3.org/1999/xhtml'>
>> <td xmlns='http://www.w3.org/1999/xhtml'>Name
>> ...
>> would be very compatible with XMPP clients. And would put much more
>> bytes on the wire than neccessary.
>
> Oh, no one is saying this is the XML we should render, and nor do we
> currently. Instead, the renderer keeps a stack of the default
> namespaces and only outputs the xmlns attribute when needed. This is
> the same as the "renderers" (most APIs use the term "writer") does in
> the other previously mentioned APIs.
So basically, you're proposing to design an API which requires saying:
* I want to use ns 'http:123' on element 'iq'
* I still want to use ns 'http:123' on inner element 'query'
* I still want to use ns 'http:123' on inner element 'items'
* Yes, I still want to use ns 'http:123' on inner element 'item', really!
which is redundant. And you justify this by emphasizing that everybody
else does which is ok from an XML parser PoV, but not so much from a
Vysper PoV.
Why? Because the impact of implementing this would be:
* Changing a lot of working code, potentially introducing bugs, without
adding any information which isn't already there.
* Making stanza creation much more verbose, cluttering namespaces all
over the place.
* Tracking everywhere if a stream is c2s or s2s, to appropriately be
able to add xmlns='jabber:client' vs. xmlns='jabber:server'
I don't want to go through all this.
If the renderer/writer is intelligent enough to derive the ns, then
please let's follow "DRY", regardless of other APIs.
XMPP doesn't need a full blown XML parser. So I can see basically two
options:
1. Introduce (aka. keep) ways to make the renderer intelligent enough
(well, effectively make the API intelligent enough).
2. Rollback Vysper to it's own, buggy-but-sufficient XML handling code.
Bernd
Re: [Vysper] XML Namespaces [WAS: Re: Moving new nbxml in trunk]
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Sun, May 9, 2010 at 9:52 PM, Bernd Fondermann <bf...@brainlounge.de> wrote:
> This example is especially appropriate, as it includes beer:
We like that of course :-)
> <?xml version='1.0'?>
> <Beers>
> <!-- the default namespace inside tables is that of HTML -->
> <table xmlns='http://www.w3.org/1999/xhtml'>
> <th><td>Name</td><td>Origin</td><td>Description</td></th>
> <tr>
> <!-- no default namespace inside table cells -->
> <td><brandName xmlns="">Huntsman</brandName></td>
> <td><origin xmlns="">Bath, UK</origin></td>
> <td>
> <details xmlns=""><class>Bitter</class><hop>Fuggles</hop>
> <pro>Wonderful hop, light alcohol, good summer beer</pro>
> <con>Fragile; excessive variance pub to pub</con>
> </details>
> </td>
> </tr>
> </table>
> </Beers>
>
> Now, I'd like to have an API like this:
> builder.add("table", "http://www.w3.org/1999/xhtml").
> add("th").
> add("tf").
> addText("Name") ...
>
> and *not*
> builder.add("table", "http://www.w3.org/1999/xhtml").
> add("th", "http://www.w3.org/1999/xhtml").
> add("tf", "http://www.w3.org/1999/xhtml").
> addText("Name") ...
>
> while you'd like it the other way round, right?
Yes (of course, you would likely use a constant rather than a string,
but that's besides the point here).
> Reason for my position: This is straihtforward. You don't redefine java
> variables when a new scope opens. You'd just redefine them to
> shadow/override the outer scoped variable.
> The inner XML elements are not arbitrary. Within a table, you'd expect
> td, tr etc. to occur. No need to redefine the namespace.
> However, if non-table elements occur, the namespace gets reset explicitly.
I'm not sure I follow along perfectly well here. But, I'll attempt to
give an example of why I think inheriting the namespace in the XML
creation step would be confusing. Let's take the following function
that creates <item> elements in a MUC implementation:
private XMLElement createItem(XMLElementBuilder builder) {
builder.startInnerElement("item");
...
}
Now, in MUC, <item> elements can be contained both in the
http://jabber.org/protocol/muc#user and
http://jabber.org/protocol/muc#admin namespaces. Which one would this
be in? To find out, I would have to backtrack to code to find out
where the parent <x> element is created and see what namespace that is
in. I would rather prefer the namespace be explicit.
> And I don't think you can get rid of looking up outer namespaces in any
> serious implementation. In the second example, where every add() has an
> explicit namespace declaration, one would
> * either repeatedly render the declared xmlns on every element, no
> tracking of outer ns needed
> * or, not repeat rendering the declared xmlns, (like *all* XML examples
> I've seen so far) which can only be achieved by keeping track of what
> the current namespace is.
>
> I don't think XML like this:
> <table xmlns='http://www.w3.org/1999/xhtml'>
> <th xmlns='http://www.w3.org/1999/xhtml'>
> <td xmlns='http://www.w3.org/1999/xhtml'>Name
> ...
> would be very compatible with XMPP clients. And would put much more
> bytes on the wire than neccessary.
Oh, no one is saying this is the XML we should render, and nor do we
currently. Instead, the renderer keeps a stack of the default
namespaces and only outputs the xmlns attribute when needed. This is
the same as the "renderers" (most APIs use the term "writer") does in
the other previously mentioned APIs.
/niklas
Re: [Vysper] XML Namespaces [WAS: Re: Moving new nbxml in trunk]
Posted by Bernd Fondermann <bf...@brainlounge.de>.
Niklas Gustavsson wrote:
> On Sun, May 9, 2010 at 8:23 PM, Bernd Fondermann <bf...@brainlounge.de> wrote:
>> What I wanted to achieve with the initial implementation, is that
>> namespaces get propagated automatically within the scope. That's also my
>> notion of how XML default namespaces are scoped and what the patch is
>> solving.
>
> This would go against every XML API I know of. For example, what would
> be the namespace of an element if I use it outside of its original
> parent?
>
> Also, the namespace URI of an element is just as important as its
> local name, so, I would rather this be explicit when we create an
> element, than having to backtrace in the code whatever namespace the
> parent might have.
>
>> So my resultion would be:
>> + propagating default namespaces to inner elements is implicit. (means:
>> possible reverting revision 941337, which is an strange revision number
>> anyway ;-)
>
> Again, I would be strongly against this. It would make the Vysper XML
> API work completely different from all the XML APIs (Java or not) I've
> ever used. And I believe that's true for many other developers. The
> XML APIs that I'm familiar with that behaves like this are DOM (Java
> and Javascript), XOM, JDOM, DOM4J, .Net XmlDocument and SAX (yes, I'm
> somewhat of an XML geek :-).
ok, let's talk more on code, so I can be sure to understand correctly.
I'm argueing alongside the last example in
http://www.w3.org/TR/REC-xml-names/ , chapter 6.2
This example is especially appropriate, as it includes beer:
<?xml version='1.0'?>
<Beers>
<!-- the default namespace inside tables is that of HTML -->
<table xmlns='http://www.w3.org/1999/xhtml'>
<th><td>Name</td><td>Origin</td><td>Description</td></th>
<tr>
<!-- no default namespace inside table cells -->
<td><brandName xmlns="">Huntsman</brandName></td>
<td><origin xmlns="">Bath, UK</origin></td>
<td>
<details xmlns=""><class>Bitter</class><hop>Fuggles</hop>
<pro>Wonderful hop, light alcohol, good summer beer</pro>
<con>Fragile; excessive variance pub to pub</con>
</details>
</td>
</tr>
</table>
</Beers>
Now, I'd like to have an API like this:
builder.add("table", "http://www.w3.org/1999/xhtml").
add("th").
add("tf").
addText("Name") ...
and *not*
builder.add("table", "http://www.w3.org/1999/xhtml").
add("th", "http://www.w3.org/1999/xhtml").
add("tf", "http://www.w3.org/1999/xhtml").
addText("Name") ...
while you'd like it the other way round, right?
Reason for my position: This is straihtforward. You don't redefine java
variables when a new scope opens. You'd just redefine them to
shadow/override the outer scoped variable.
The inner XML elements are not arbitrary. Within a table, you'd expect
td, tr etc. to occur. No need to redefine the namespace.
However, if non-table elements occur, the namespace gets reset explicitly.
And I don't think you can get rid of looking up outer namespaces in any
serious implementation. In the second example, where every add() has an
explicit namespace declaration, one would
* either repeatedly render the declared xmlns on every element, no
tracking of outer ns needed
* or, not repeat rendering the declared xmlns, (like *all* XML examples
I've seen so far) which can only be achieved by keeping track of what
the current namespace is.
I don't think XML like this:
<table xmlns='http://www.w3.org/1999/xhtml'>
<th xmlns='http://www.w3.org/1999/xhtml'>
<td xmlns='http://www.w3.org/1999/xhtml'>Name
...
would be very compatible with XMPP clients. And would put much more
bytes on the wire than neccessary.
Am I missing something?
Bernd
Re: [Vysper] XML Namespaces [WAS: Re: Moving new nbxml in trunk]
Posted by Niklas Gustavsson <ni...@protocol7.com>.
On Sun, May 9, 2010 at 8:23 PM, Bernd Fondermann <bf...@brainlounge.de> wrote:
> What I wanted to achieve with the initial implementation, is that
> namespaces get propagated automatically within the scope. That's also my
> notion of how XML default namespaces are scoped and what the patch is
> solving.
This would go against every XML API I know of. For example, what would
be the namespace of an element if I use it outside of its original
parent?
Also, the namespace URI of an element is just as important as its
local name, so, I would rather this be explicit when we create an
element, than having to backtrace in the code whatever namespace the
parent might have.
> So my resultion would be:
> + propagating default namespaces to inner elements is implicit. (means:
> possible reverting revision 941337, which is an strange revision number
> anyway ;-)
Again, I would be strongly against this. It would make the Vysper XML
API work completely different from all the XML APIs (Java or not) I've
ever used. And I believe that's true for many other developers. The
XML APIs that I'm familiar with that behaves like this are DOM (Java
and Javascript), XOM, JDOM, DOM4J, .Net XmlDocument and SAX (yes, I'm
somewhat of an XML geek :-).
/niklas