State of the project

[etorreborre]

Hi Daniel,

Can you please tell us:

• what's the state of the project?
• what remains to be done?
• who's already using it (at home, in production)?
• if it will ever be included in the standard lib?
• if you found a better name :-)?

Thanks,

Eric.

[etorreborre]

Obviously, I forgot to read the todo-list: http://dl.dropbox.com/u/1679797/anti-xml-todo.html.

Only questions 3 and 4 really remain.

E.

[Daniel Spiewak]

• what's the state of the project?

In development.  There are currently three developers (including myself) who are contributing on and off.  The primary roadblock is my perpetually-full schedule.  Daniel Beskin deserves a shout-out here with his recent complete rewrite of the n-hole zipper, adding support for deep-selection (and future operations as well).

In terms of whether or not Anti-XML is "production ready", I'd say it depends.  We have a quite extensive test suite that actually has reasonably comprehensive coverage on the main sources.  I haven't been able to run a code coverage report in a while (basically since 2.9.0 came out), but the test suite has been fairly well maintained since then, so I imagine we're still in good shape.  With that said, we're still changing things.  I don't consider APIs to be sacred until they've hit 1.0, and we're still working on 0.3.  The core stuff is probably solid, but you never know!  :-)

I would like nothing better than to see people using Anti-XML, filing bugs and submitting pull requests.  However, if you jump on the happy train today, you need to be willing to work with a framework that's still very much in motion.

• what remains to be done?

Right now, my main goal is to get Daniel Beskin's deep zipper stuff fully merged into master, cleaned up and functional.  Once that's done, I'll probably cut v0.3 then and there.  After that, we've got two new selection methods incoming: single-level and short-circuit deep-select.  Those will land very quickly, thanks to the flexibility of Beskin's zipper implementation.  My main concern moving forward is testing, performance, documentation and stabilization.  What would be really awesome is to hear how the framework behaves in practice and whether or not the API is really as practically-nice as I think it is.

We still do have an outstanding experiment from David LaPalomento in the area of stream parsing with a tree API.  That's probably not going to land any time soon though.

In a peripheral vein, there is actually a change to the language that is on my plate to finish involving generification of the XML literals baked into Scala itself.  This change will make it possible to use the XML literals to generate Anti-XML structures, scala.xml structures, or even something weirder like org.w3c.dom structures!  It's not strictly Anti-XML work (in fact, it's scalac), but it is important for the future of the library.

• who's already using it (at home, in production)?

I've heard from a number of people including Tony Morris, Jon Pretty and Jon-Anders Teigen.  I don't know of anyone specifically who is really using it, but then not everyone tells me these things (I only found out about Jon and Jon-Anders through conversation along other lines).

• if it will ever be included in the standard lib?

That's the plan!  The first thing that needs to happen is the generification of the XML literals.  (note that this will not change anything with the XML pattern matching, which is basically broken beyond repair and shouldn't be used for anything, scala.xml or otherwise)  After that, the next priority is stabilization of the Anti-XML library itself.  Once we're basically happy with what we see, Anti-XML will be moved over into a (currently nascent) scala-contrib library.  If it meets with community approval in that position, it will be moved over into the standard library.

It's important to note that Anti-XML will never replace scala.xml.  It's simply not backwards compatible.  For the same reason, XML literals will continue generating scala.xml structures by default for the foreseeable future.  The plan is for Anti-XML to sit along-side scala.xml in the standard library (obviously in a different package) and be the de facto "preferred" XML library.

• if you found a better name :-)?

:-)  I think it's probably too late to change the name at this point.  After all, how many other names are there with available domains?

Daniel

[Martin Kneissl]

I would like nothing better than to see people using Anti-XML, filing bugs and submitting pull requests.  However, if you jump on the happy train today, you need to be willing to work with a framework that's still very much in motion.

I have recently started using Anti-XML. First, I thought: "Where's the public API?", and then realized that I'd been looking for the the standard collections API :) . Anti-XML looks very good.

Actually like the name, mostly because of my love-hate relationship to XML.

Where can I read more on the stream parsing API experiment? That's something I might need sooner or later in my application.

Martin.

[Alois Cochard]

Hello All,

Thanks for the detailed roadmap Daniel!

Just wanna say that imo it's not too late to change the name, until
you reach 1.0 and freeze API I don't see any problem with changing
name...
I'm not really constructive here because I don't have any alternative
proposition, but I'm not sure "anti-xml" is well suited, specially for
new comer who could think this lib is build to do something "against"
XML.

By the way, thanks for the great work/effort, I'm really looking
forward using the lib in production (or integrating it in other
framework...), but for the moment only played with it at home or on
small project.

Best regards,

Alois Cochard
http://www.twitter.com/aloiscochard
http://aloiscochard.blogspot.com

On Sep 21, 6:34 am, Daniel Spiewak <djspie...@gmail.com> wrote:
> >    - what's the state of the project?

>
> > In development.  There are currently three developers (including myself)
>
> who are contributing on and off.  The primary roadblock is my
> perpetually-full schedule.  Daniel Beskin deserves a shout-out here with his
> recent complete rewrite of the n-hole zipper, adding support for
> deep-selection (and future operations as well).
>
> In terms of whether or not Anti-XML is "production ready", I'd say it
> depends.  We have a quite extensive test suite that actually has reasonably
> comprehensive coverage on the main sources.  I haven't been able to run a
> code coverage report in a while (basically since 2.9.0 came out), but the
> test suite has been fairly well maintained since then, so I imagine we're
> still in good shape.  With that said, we're still changing things.  I don't
> consider APIs to be sacred until they've hit 1.0, and we're still working on
> 0.3.  The core stuff is probably solid, but you never know!  :-)
>
> I would like nothing better than to see people using Anti-XML, filing bugs
> and submitting pull requests.  However, if you jump on the happy train
> today, you need to be willing to work with a framework that's still very
> much in motion.
>
>
>

> >    - what remains to be done?

>
> > Right now, my main goal is to get Daniel Beskin's deep zipper stuff fully
>
> merged into master, cleaned up and functional.  Once that's done, I'll
> probably cut v0.3 then and there.  After that, we've got two new selection
> methods incoming: single-level and short-circuit deep-select.  Those will
> land very quickly, thanks to the flexibility of Beskin's zipper
> implementation.  My main concern moving forward is testing, performance,

> documentation and stabilization.  What would be *really* awesome is to hear

> how the framework behaves in practice and whether or not the API is really
> as practically-nice as I think it is.
>
> We still do have an outstanding experiment from David LaPalomento in the
> area of stream parsing with a tree API.  That's probably not going to land
> any time soon though.
>
> In a peripheral vein, there is actually a change to the language that is on
> my plate to finish involving generification of the XML literals baked into
> Scala itself.  This change will make it possible to use the XML literals to
> generate Anti-XML structures, scala.xml structures, or even something
> weirder like org.w3c.dom structures!  It's not strictly Anti-XML work (in
> fact, it's scalac), but it is important for the future of the library.
>
>
>

> >    - who's already using it (at home, in production)?

>
> > I've heard from a number of people including Tony Morris, Jon Pretty and
>
> Jon-Anders Teigen.  I don't know of anyone specifically who is

> *really*using it, but then not everyone tells me these things (I only

> found out
> about Jon and Jon-Anders through conversation along other lines).
>
>
>

> >    - if it will ever be included in the standard lib?

>
> > That's the plan!  The first thing that needs to happen is the
>

> generification of the XML literals.  (note that this will *not* change

> anything with the XML pattern matching, which is basically broken beyond
> repair and shouldn't be used for anything, scala.xml or otherwise)  After
> that, the next priority is stabilization of the Anti-XML library itself.
> Once we're basically happy with what we see, Anti-XML will be moved over
> into a (currently nascent) scala-contrib library.  If it meets with
> community approval in that position, it will be moved over into the standard
> library.
>

> It's important to note that Anti-XML will never *replace* scala.xml.  It's

> simply not backwards compatible.  For the same reason, XML literals will

> continue generating scala.xml structures *by default* for the foreseeable

> future.  The plan is for Anti-XML to sit along-side scala.xml in the
> standard library (obviously in a different package) and be the de facto
> "preferred" XML library.
>
>
>

> >    - if you found a better name :-)?

[Daniel Sobral]

On Wed, Sep 21, 2011 at 03:18, Alois Cochard <alois....@gmail.com> wrote:
> Hello All,
>
> Thanks for the detailed roadmap Daniel!
>
> Just wanna say that imo it's not too late to change the name, until
> you reach 1.0 and freeze API I don't see any problem with changing
> name...
> I'm not really constructive here because I don't have any alternative
> proposition, but I'm not sure "anti-xml" is well suited, specially for
> new comer who could think this lib is build to do something "against"
> XML.

We could always call it Ant iXML, and leverage on two well known brand
names. :-)

--
Daniel C. Sobral

I travel to the future all the time.

[Daniel Spiewak]

Where can I read more on the stream parsing API experiment? That's something I might need sooner or later in my application.

The only real code that's out there is here: https://github.com/dmlap/anti-xml/tree/lazy-group  It's still extremely early and has a number of problems that we need to solve.  I'm actually not sure if David is still working on it, but there you go.  If someone is interested in attacking this effort, I would be more than happy to lay out all of the thought and design that has gone into it to date as well as the ultimate vision for how it will work.

Daniel

[Daniel Spiewak]

There have certainly been one or two people who have found the "Anti-XML" name to be confusing.  By and large though, it seems to be fairly well-understood.  There are three problems with changing the name at this point:

• Package name change, and thus API breakage (doesn't really worry me)
• Domain availability (good *.com and *.org names are extremely rare nowadays; we got pretty lucky in that Anti-XML corresponded to available domains)
• General awareness (people know the name now)

I think the last point is the most salient one.  A ton of people now know the name "Anti-XML".  We've had presentations, tweets, discussions, all using the name "Anti-XML".  Changing it now would be confusing, I think.

Daniel

[etorreborre]

I thought about the naming again.

> Domain availability (good *.com and *.org names are extremely rare nowadays; we got pretty lucky in that Anti-XML corresponded to available domains)

I think that this is the only issue. Maybe something like http://scala.xml2.org (or http://scala.other-name.org) is available?

> General awareness (people know the name now)

On the other hand I don't think that this is an issue really. Daniel, you have enough followers everywhere so that the word will spread out pretty fast about a new naming. I'm more worried about the thousands of users which will have to use version 1.0 and following forever. If I imagine someone new coming to scala in 2 or 3 years, I guess that he/she will find the "antixml" name counter-intuitive. What if we had anti-io in Java or anti-collections in Scala? Anti-xml was a good name to start the project and gather focus/interest but now I'd rather see it replaced by something else.

Sorry that I don't have the depth to discuss other matters like the stream parsing API but I feel that this is an important question for the community.

Eric.

[Daniel Spiewak]

On the other hand I don't think that this is an issue really. Daniel, you have enough followers everywhere so that the word will spread out pretty fast about a new naming. I'm more worried about the thousands of users which will have to use version 1.0 and following forever. If I imagine someone new coming to scala in 2 or 3 years, I guess that he/she will find the "antixml" name counter-intuitive. What if we had anti-io in Java or anti-collections in Scala? Anti-xml was a good name to start the project and gather focus/interest but now I'd rather see it replaced by something else.

All good points.  I think the best time to change the name will be during the move to scala-contrib.  That's also when the package name will change, so it just makes sense to get all of the renaming out of the way in one jump.

Daniel