We just discovered a glitch on the XML 2005 conference web site that meant that submissions for the Posters and Artwork were lost; please resubmit (we found the problem). Sorry for the inconvenience!
The final schedule is up on the XML 2005 web site and I think it’s the best yet (maybe I say that every year, but there are some really good talks on the program this year). We have big companies talking about what they’re doing, small companies talking about new technologies, and independent people talking about what they’re cooking up in their basements or garages. There are talks for the newcomers to XML, talks for the cynics, and talks for those in between, so take a look!
And of course the tutorials are available for registration; I’d urge everyone who is interested in attending a tutorial to register as soon as possible. If we don’t get enough registrants for some tutorials we need to cancel them, which is disappointing for the conference, and the tutorial presenter, and especially for people who wanted to attend the tutorial but didn’t register in time. You don’t need to attend the conference to attend a tutorial; we try to be flexible to meet attendees’ needs (personally I think you should, of course, but everyone has different ideas as to what they want to do in any given year).
There are also more ways to take part in the conference: every registered conference attendee, as well as registered booth staff, can put up a poster (or two). Posters can be on any (reasonable) subject; posters on new product ideas, new technology ideas, forming groups to work on either of the above, advertising your availability for full-time hire, or advertising your consulting services are all welcome. The poster deadline for guaranteed space is November 4; space may be available at the conference as well, but that’s not guaranteed.
We also have an artwork exhibit each year to show how technology and artistry are not mutually exclusive; any ideas are welcome. These pieces are shown next to the pieces in the exhibit hall, so anyone can admire your work, whether signed or anonymous. Deadline to guarantee space is October 28; there may be space available later as well.
It’s going to be a fun and interesting conference again this year, I can just tell!
Shelley’s posting Maids, Mommies, and Mistresses made me decide to throw in my own few cents on what makes a good conference submission, and how talks are accepted, to add to what Kathy Sierra and Adam Trachtenburg said (and there are good points in both). I’ve chaired a conference since 2001, organized tracks, and been a speaker at various conferences for many years, so I know something about the subject.
Number 1 has to be: if there are guidelines, read them and act on them! The conference organizers wrote them for a reason. I’m always amazed how many people obviously don’t read the ones I have for XML 2005 at Abstract Writing Hints — we get abstracts that are two sentences long, with misspellings, and acronyms used wrongly. The reviewers unceremeniously dump all of these.
I’ve been involved in lots of conferences and they range from the peer-reviewed to the “people we know or who pay get preference”; you need to figure out which conference you want to speak at and why, and which system they use, and how to have your talk accepted in that system. If the information isn’t on the conference web site about how talks are selected, email someone from the organizing committee and ask! Or find the name of a speaker from the previous year and ask them — most people don’t mind a brief polite email asking how they got on the program.
At the XML 2005 Conference I chair we use a blind peer review process to grade the abstracts. The Planning Committee then takes those grades and looks for program balance to cover interesting topics, knowing who the speakers are. This sort of system means that if you write a good abstract on an interesting topic, that isn’t topped by an even better abstract on a related topic, you’ll find yourself on the program. (Keynotes are a different story, of course, they’re invited). Most of the speakers each year are new speakers; some are “perennials” but that’s because they are involved in interesting work and know how to describe it in ways that make the reviewers want to attend the talk. The blind review system is biased towards submitters who can explain what they’re doing and why it’s interesting in 500 words or less, but I figure that’s a reasonable indicator for being a good speaker as well. It doesn’t always work that way (and we collect attendee reviews of the speakers each year to catch those cases), but usually it does. Oh, and another thing — it’s so much easier to have 100+ people help us figure out which talks are good than to rely on only 7 people on a Planning Committee!
The final piece of advice I’d give, once your talk is accepted, is to practise, if you’re not an experienced speaker. Even better, record your talk (audio and video) and watch the video to figure out what you can do better. Practise to yourself, the cat, or your family. Doing some professional training is good, but being familiar with the material so you’re not talking to the projected slides, or your notes, is better. Being prepared for likely questions is also good, and having a couple of “proposed” questions to give the chair of your session should nobody in the audience have questions never hurts. In other words, be prepared!
Now that the XML Catalog specification has been approved as an OASIS Standard, it feels like the end of an era to me. I’ve been chairing the Entity Resolution Technical Committee since its inception way back in October 2000 , working with a good group of people. As Norm put it today, we’d be happy to work on any standard with this group. Everyone working together, no posturing, no weird agendas, just people trying to find the best solution to a problem. It made the group easy to chair, and I’m confident the results reflect that; I can’t help but suspect that dysfunctional committee politics results in specifications that are not as good as they could have been.
So I’m a little nostalgic right now, remembering the first discussions, the meetings at conferences, as well as the break we took in the middle before deciding to go for that “OASIS Standard” moniker. The TC still has 3 of the original 4 co-proposers (Norm Walsh, Paul Grosso, and me; John Cowan had to pull out part-way through due to work obligations). New people joined, and others left, but overall we had a pretty stable group.
So I want to thank the members of the ER TC, both past and present, and also Mary McRae and Robin Cover of OASIS. Your good humour, desire to do the right thing, and willingness to put in the effort all meant a lot and made it possible to finalize the specification and show members of OASIS why it’s useful. I’d also like to thank the implementors of the catalog spec who proved that it’s implementable! I believe catalogs will be widely used in the future, even if, like much XML plumbing, people won’t actually see a catalog very often.
So feel free to drop by the Sun booth at XML 2005 to talk about catalogs; either Norm or I are likely to be there and Norm will have his catalog implementation on his laptop to show people (along with a bunch of other things, of course).