BUG: Broken handling of redefined default namespace

Florian,

Could you possibly put together a minimal self-contained example that does
not depend on external websites? That example can then be used to debug the
code, and as a test case for a future regression test once the bug is fixed.

As a matter of fact, we are currently very much in need of additional help
to address a number of pending bugs with the XML code; some of them can be
seen at:

http://lampsvn.epfl.ch/trac/scala/query?status=assigned&status=new&statu...

If anyone feels like helping us with the Scala XML support code, please let
us know!!
Toni

Florian Hars wrote:
> This is a bug in scalas xml library. I would report it in trac if trac
> wouldn't send me into an infinite redirect loop.
>
> The blog of Sam Ruby is HTML5 with
>
> and contains svg elements that start with
>
>
> If you load this in scala, you get an svg element with two default
> namespaces:
>
> (new scala.xml.parsing.NoBindingFactoryAdapter load
> "http://intertwingly.net/blog") \\ "svg"
> res8: scala.xml.NodeSeq =
> xmlns="http://www.w3.org/2000/svg" xmlns="http://www.w3.org/1999/xhtml">
> ...
>
> - Florian
>

Antonio Cunei wrote:
> Could you possibly put together a minimal self-contained example that
> does not depend on external websites? That example can then be used to
> debug the code, and as a test case for a future regression test once
> the bug is fixed.
> scala>
> |
> |
> res0: scala.xml.Elem = ...
> scala> res0 \ "b"
> res1: scala.xml.NodeSeq = xmlns="urn:example.com:a">
> scala> res1(0).scope
> res2: scala.xml.NamespaceBinding = xmlns="urn:example.com:b"
> xmlns="urn:example.com:a"
The "a" declaration shouldn't be here--b's default namespace declaration
should override a's.
> scala> res1(0).namespace
> res3: String = urn:example.com:b
This is correct, however.
> As a matter of fact, we are currently very much in need of additional
> help to address a number of pending bugs with the XML code; some of
> them can be seen at:
>
> http://lampsvn.epfl.ch/trac/scala/query?status=assigned&status=new&statu...
>
>
> If anyone feels like helping us with the Scala XML support code,
> please let us know!!
I hereby volunteer! Unfortunately I don't have a whole lot of time in
the next month or so to work on it, but after that I should be able to
throw at least a handful of hours a week at it.

-0xe1a

Alex Cruise wrote:
> Antonio Cunei wrote:
>> If anyone feels like helping us with the Scala XML support code,
>> please let us know!!
> I hereby volunteer! Unfortunately I don't have a whole lot of time in
> the next month or so to work on it, but after that I should be able to
> throw at least a handful of hours a week at it.
>

Alex,

Thank you very much indeed for your offer!! Any help is extremely welcome.
Once you feel you can start devoting some time to this task, please just
let me know.

If more people show interest in working on the XML support, we can form a
team and a discussion group for the topic, which will make working
collaboratively on it more enjoyable!

In the meantime, thank you!

Anyone else interested in supporting XML on Scala? :) If so, let us know!
Toni

On Jan 27, 2009, at 11:33 AM, Antonio Cunei wrote:
> Alex Cruise wrote:
>> Antonio Cunei wrote:
>>> If anyone feels like helping us with the Scala XML support code,
>>> please let us know!!
>> I hereby volunteer! Unfortunately I don't have a whole lot of time
>> in the next month or so to work on it, but after that I should be
>> able to throw at least a handful of hours a week at it.In the
>> meantime, thank you!
>
> Anyone else interested in supporting XML on Scala? :) If so, let us
> know!

I am interested!

Cheers,
--
Normen Müller

Normen Müller wrote:
> On Jan 27, 2009, at 11:33 AM, Antonio Cunei wrote:
>> Alex Cruise wrote:
>>> I hereby volunteer! Unfortunately I don't have a whole lot of time
>>> in the next month or so to work on it, but after that I should be
>>> able to throw at least a handful of hours a week at it.In the
>>> meantime, thank you!
>>
>> Anyone else interested in supporting XML on Scala? :) If so, let us know!
>
> I am interested!
>

Normen, this is great! I think we can start organizing a Scala XML team! We
have so far:

- Michael Fogus
- Alex Cruise
- Normen Müller

Some interest was also interest expressed by the Lift developers, I believe
some of them may also become part of this group (David Pollak?).

On our side, we will be glad to give the XML team all the necessary
support. That includes SVN commit rights, a mailing list or forum (or both)
as needed, and any other support that may be required. You can also set up
a Google Group or another infrastructure, of course.

We will need one reference person in the group, however, who can keep track
of the overall progress and co-ordinate things when needed. Would any of
you be willing to assume this role?

In the meantime, we have created an XML component on Trac, and are
assigning to it our pending tickets so that they are easier to find:

http://lampsvn.epfl.ch/trac/scala/query?status=assigned&status=new&statu...

Toni

Hi David, all:

We got great feedback for our call for XML contributors. So we thought
the best thing to do is form a group of people who are interested in
maintaining the XML libraries together. Besides you (or somebody else
from the lift side), there's Michale Fogus, Alex Cruise, and Normen
Mueller. What I would suggest is that you cross-review patches between
yourselves and then commit them youselves. Toni Cunei will set up the
group and explain details.

Thanks to everyone for volunteering!

Martin and Co.,
Cool.  I've got very little bandwidth to do anything other than fixing bugs between now and the end of February (the book deadline and the Lift 1.0 launch are both on 2/26).
It'd be super-great if someone else signed up as the project coordinator.  Otherwise, I'm cool with fixing bugs and making enhancements.
Thanks,
David

On Tue, Jan 27, 2009 at 9:45 AM, martin odersky <martin.odersky@epfl.ch> wrote:

Hi David, all:

We got great feedback for our call for XML contributors. So we thought
the best thing to do is form a group of people who are interested in
maintaining the XML libraries together. Besides you (or somebody else
from the lift side), there's Michale Fogus, Alex Cruise, and Normen
Mueller. What I would suggest is that you cross-review patches between
yourselves and then commit them youselves. Toni Cunei will set up the
group and explain details.

Thanks to everyone for volunteering!

 -- Martin


On Tue, Jan 27, 2009 at 6:34 PM, Antonio Cunei <scala_ml@cunei.com> wrote:
> Normen Müller wrote:
>>
>> On Jan 27, 2009, at 11:33 AM, Antonio Cunei wrote:
>>>
>>> Alex Cruise wrote:
>>>>
>>>> I hereby volunteer!  Unfortunately I don't have a whole lot of time in
>>>> the next month or so to work on it, but after that I should be able to throw
>>>> at least a handful of hours a week at it.In the meantime, thank you!
>>>
>>> Anyone else interested in supporting XML on Scala? :) If so, let us know!
>>
>> I am interested!
>>
>
> Normen, this is great! I think we can start organizing a Scala XML team! We
> have so far:
>
> - Michael Fogus
> - Alex Cruise
> - Normen Müller
>
> Some interest was also interest expressed by the Lift developers, I believe
> some of them may also become part of this group (David Pollak?).
>
> On our side, we will be glad to give the XML team all the necessary support.
> That includes SVN commit rights, a mailing list or forum (or both) as
> needed, and any other support that may be required. You can also set up a
> Google Group or another infrastructure, of course.
>
> We will need one reference person in the group, however, who can keep track
> of the overall progress and co-ordinate things when needed. Would any of you
> be willing to assume this role?
>
> In the meantime, we have created an XML component on Trac, and are assigning
> to it our pending tickets so that they are easier to find:
>
> http://lampsvn.epfl.ch/trac/scala/query?status=assigned&status=new&status=reopened&component=XML+support&order=priority&col=id&col=summary&col=status&col=type&col=priority&col=version
>
> Toni
>
>

--
Lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

Antonio Cunei wrote:
> On our side, we will be glad to give the XML team all the necessary
> support. That includes SVN commit rights, a mailing list or forum (or
> both) as needed, and any other support that may be required. You can
> also set up a Google Group or another infrastructure, of course.
Personally I'd prefer that we use a list on listes.epfl.ch, and IMO it's
probably best to create a new list, since a significant proportion of
the community couldn't care less about XML (to put it mildly... ;)
> We will need one reference person in the group, however, who can keep
> track of the overall progress and co-ordinate things when needed.
> Would any of you be willing to assume this role?
I'll do it if no one else speaks up. If someone does, I guess we can
arm wrestle. ;)
> In the meantime, we have created an XML component on Trac, and are
> assigning to it our pending tickets so that they are easier to find:
Great!

-0xe1a

On Jan 27, 2009, at 7:47 PM, Alex Cruise wrote:
> I'll do it if no one else speaks up. If someone does, I guess we
> can arm wrestle. ;)
>> In the meantime, we have created an XML component on Trac, and are
>> assigning to it our pending tickets so that they are easier to find:

I would also volunteer, but if Alex wants to do it I don't dare to
wrestle with him ;-)

Cheers,
--
Normen Müller

Normen Müller wrote:
> On Jan 27, 2009, at 7:47 PM, Alex Cruise wrote:
>> I'll do it if no one else speaks up. If someone does, I guess we can
>> arm wrestle. ;)
>>> In the meantime, we have created an XML component on Trac, and are
>>> assigning to it our pending tickets so that they are easier to find:
>
> I would also volunteer, but if Alex wants to do it I don't dare to
> wrestle with him ;-)
>

Excellent! It seems we have a team and a coordinator! :) (if that is ok for
Fogus as well, of course). Alex,

Alex Cruise wrote:
> Personally I'd prefer that we use a list on listes.epfl.ch, and IMO it's
> probably best to create a new list, since a significant proportion of
> the community couldn't care less about XML (to put it mildly... ;)

Sure! I will arrange to have a "scala-xml" mailing list created on
listes.epfl.ch as requested, with an archive on Gmane. I will also link the
list to Trac, so that the list is automatically notified of new XML tickets.

Further, in order to grant SVN commit rights to the members of the group,
we need all contributors to submit a signed Contributor Licence Agreement;
this is a necessary step in order to prevent possible problems with
intellectual property rights and similar legal nonsense. If you haven't
done so already, please complete and send us a copy of the form, which can
be found at:

http://www.scala-lang.org/sites/default/files/contributor_agreement.pdf

We will grant SVN commit rights as the forms arrive. I will send a
confirmation message as soon as the mailing list is ready.
Thanks!!
Toni

Alex Cruise wrote:
> I'll do it if no one else speaks up. If someone does, I guess we can
> arm wrestle. ;)
After some reflection I feel like this came across as a bit aggressive;
that was absolutely not my intention!

In fact, a big part of my rationale for volunteering for the coordinator
bit was that I expect to be less useful than others when it comes to
coding, but still want to pull my weight! :)

-0xe1a

On Jan 27, 2009, at 10:13 PM, Antonio Cunei wrote:
> http://www.scala-lang.org/sites/default/files/
> contributor_agreement.pdf

I'll send the form by the end of this week cause I am currently
traveling.

Just a few questions in advance:
o Who is going to be the coordinator now?
o Are we getting a short introduction to the used infrastructure/
practices (e.g. Trac/ Subversion/ Peer-Reviewing of Code/ Compiling
Scala-XML branch/ ...)?

Cheers,
--
Normen Müller

Normen Müller wrote:
> On Jan 27, 2009, at 10:13 PM, Antonio Cunei wrote:
>> http://www.scala-lang.org/sites/default/files/contributor_agreement.pdf
>
> I'll send the form by the end of this week cause I am currently traveling.
>
> Just a few questions in advance:
> o Who is going to be the coordinator now?

I think we agreed that Alex will take this role. In practice that basically
means being a reference contact if people need to know something about the
XML support (or if they would like to contribute to the effort), and
generally just keeping an eye on things.

> o Are we getting a short introduction to the used infrastructure/
> practices (e.g. Trac/ Subversion/ Peer-Reviewing of Code/ Compiling
> Scala-XML branch/ ...)?
>

This is an excellent point. I should probably write some sort of quick
guide, but in practice:

1) We use SVN for the repository. The address is:
http[s]://lampsvn.epfl.ch/svn-repos/scala//

Most development takes place in scala/trunk; if you are a developer you
will generally check out: https://lampsvn.epfl.ch/svn-repos/scala/scala/trunk

The SVN repository can also be browsed by using the Trac interface, the
address is: http://lampsvn.epfl.ch/trac/scala/browser

A nice feature of the Trac browser is that every subdir can be monitored
with an RSS feed (click on "Revision Log", and "RSS" at the bottom). So,
for instance, if you want to monitor changes to
scala/trunk/src/library/scala/xml, you can directly subscribe to the feed:
http://lampsvn.epfl.ch/trac/scala/log/scala/trunk/src/library/scala/xml?...

In general we create separate branches when there are new experimental
developments, that need an initial stage of unstable development before
they can be merged in. In the case of the XML support, the developments are
likely to be more incremental, and to consist mostly of fixes; there is
therefore no reason for a separate branch (unless you want to rewrite the
whole XML support code, of course!). Commits to trunk should be appropriate.

2) The Trac bug database is at: https://lampsvn.epfl.ch/trac/scala/query.
If you don't have an account yet, you can create one at any time. New
tickets are created by users who encounter bugs or propose suggestions. We
usually receive the tickets, inspect them for validity, and assign them to
the appropriate person or group. The person the ticket is assigned to can
either accept the ticket and start working on it, or add comments, or can
reassign it to someone else, as appropriate. There are a small number of
pseudousers, used for administrative purposes. For instance:

- "scala_reviewer" is the default receiver of new tickets. New tickets are
reviewed by someone in the Core Team within a few days, and assigned as
appropriate
- the tickets that get assigned to "scala_meeting" are discussed more in
depth by the Core Team during a weekly meeting, and either dealt with on
the spot, or reassigned
- tickets that get assigned to "scala_community" are non-critical bugs or
improvements that we would have to postpone to favor more urgent bugs; we
ask for the community to help us with these features or issues, as possible

Once a certain issue is fixed, and the patch has been committed to SVN, the
ticket can be closed. The field "Fixed in version" is used to mark the
branch or version that will contain the fix; always select
"Unreleased-2.8.x" when working on trunk, as we use that marker to
automatically update our version history. Adding a comment to the ticket
with the corresponding SVN revision number is also useful.

Notably, each Trac ticket refers to some Scala component, whch in this case
will be "XML support". The database can be queried by component, which
makes it easy to find all the related bugs. For instance:

http://lampsvn.epfl.ch/trac/scala/query?status=assigned&status=new&statu...

3) In terms of code reviewing, we accept occasional contributions via email
from all users, for instance as attachments to Trac tickets. In that case
we review the patch and submit it if appropriate. For regular contributors
or maintainers, we enable direct SVN commits; there is the understanding
that all non-trivial patches are discussed beforehand in the appropriate
mailing lists or venues.

If the patch entails entirely new functionalities for Scala (anything that
exposes a change in the language, or in the visible APIs), the proposed
code change must pass an additional revision stage, which we manage using
the Revision Board software. We can create an account for you on that
system on demand, if the need arises. Once a diff is submitted to the
review board, it is carefully inspected, usually by Martin, and either
rejected or approved. We make a fairly limited use of the review board, as
it usually applies only to large or particularly delicate changes, or if
the submitter wants to make extra sure that a particular patch is in fact
appropriate.

During the regular work of the Scala XML team, it is likely that most
changes will be internally managed, discussed, and reviewed by the group.

NOTE: As part of the development of Scala, we constantly run a large
regression test suite, to make sure that already fixed bugs do not creep
back in (and they do!). Every commit related to a bug that gets fixed
should always be accompanied by a regression test that is added to the test
suite. For many tickets, the example that exposes the flaw in the ticket
description can be directly used as a regression test. Please try to add
tests to match every fixed bug, if at all possible.

4) commits. Every time some code is committed, a checkin test is run over
the resulting code, and a more extensive test is run every night. The tests
are run by our continuous integration server, Hudson, at:
http://scala-webapps.epfl.ch/hudson. Both the checkin tests and the nightly
tests have associated RSS feeds that can be monitored for failures.

Usually, it is advisable to compile the code base and to run the regression
test suite locally, before committing, in order to catch really obvious
failures to compile.

I believe the above is an overall fairly complete introduction to the
current operating procedures; if you require further details, however, just
let me know!

Toni

Hi,

On Wed, Jan 28, 2009 at 6:31 AM, Antonio Cunei wrote:

> 4) commits. Every time some code is committed, a checkin test is run over
> the resulting code, and a more extensive test is run every night. The tests
> are run by our continuous integration server, Hudson, at:
> http://scala-webapps.epfl.ch/hudson. Both the checkin tests and the nightly
> tests have associated RSS feeds that can be monitored for failures.

That hudson link is throwing 404. ;)

hemant schrieb:
>> http://scala-webapps.epfl.ch/hudson
>
> That hudson link is throwing 404. ;)

The usual servlet container madness. The correct link is

http://scala-webapps.epfl.ch/hudson/

- Florian.