|
2007-11-25, 21:18
The ISO/IEC JTC 1 SC 34 Secretariat manager has re-iterated in the latest member correspondence that the deadline is approaching for ISO/IEC members to register for the OOXML Ballot Resolution Meeting scheduled for the end of February 2008.
“I need to receive all preliminary delegate lists before December 11 (which means you can bring the list to the plenary meeting in Kyoto if you wish). National body indications of attendance at the BRM received after December 10 can only be accommodated if there is room remaining, and at this early stage it is not expected that there will be room remaining.”
Registration is open to all member bodies that voted in the 2 September 2007 ballot. The message is: register soon or risk not being able to attend the BRM …
add comment
( 499 views )
| permalink
|
stumble this |
digg it!
|
|
2007-11-16, 06:05
A Frequently Asked Questions (FAQ) document for the upcoming ISO/IEC DIS 29500 BRM has now been published on the SC 34 site here. Students of the process are advised to study it!
|
|
2007-10-24, 18:02
OOXML Will Eat Your Babies!
At least, I wouldn't be surprised to read such a headline next, judging by the self-parodic heights which the noooxml campaign has scaled with its recent video. It will be a relief when the technical work ramps up again and contentful communication is resumed.
To this end, Ecma have been busy (very busy I imagine) de-duping the national body comments. The exercise has revealed that the 3,522 submitted comments are composed of 1,030 distinct ones, and it is these which will be addressed by the ballot resolution process. The informal liaison between Ecma and National Bodies is already under way, and Ecma have established a "portal" web site (password protected) which bona fide NB members may use to view Ecma's activities on the text.
UK Activity
In the UK BSI has resolved to re-establish the 29-person technical panel IST/41/-/1 to provide BSI information on whether Ecma is resolving the UK's comments satisfactorily. It's likely this will be done using the open Wiki originally used for the panel's initial comment gathering. I am stepping down as panel convenor as part of my neutralisation process prior to chairing the BRM, and will be replaced by my able colleague (and SC 34 WG 1 convenor) Martin Bryan.
Towards a BRM FAQ
I have been working closely with ISO/IEC to write a FAQ on the BRM which seeks to shine a light into the some of the darker nooks of the JTC 1 Directives and clarify the process details. A draft is in circulation and this should be published soon. Readers of this blog should find little to surprise them, though one new piece of information is, that if the BRM agrees a new text then NBs have a whole 30 days in which they may opt to switch their vote. I predict this period may seem some intensive lobbying — especially if the vote is tight, though by that time all the technical work will, thankfully, have been done.
The Clogging of SC 34
A fair bit has been written about the paralysing effect on SC 34 of its large number of inactive new members, and some commentary has read this as a kind of strike against OOXML/Microsoft. As Rick Jelliffe has noted though, the truth is more complicated. It would be more accurate to say that the recent interest in Office formats (ODF too) has prompted the increased membership, and that a number of countries (21 in fact) have not responded to any recent ballots, causing those ballots to fail.
The situation is intolerable, and one project editor has already complained bitterly that while he has worked assiduously on his text over many years, shepherding it through its committee stage votes, it is galling to see it halted by the activity surrounding another standard that is being waved on along the red carpet, despite having failed its only vote (so far).
Ironicically, these countries did not need to join SC 34 in order to influence DIS 29500 (that's a JTC 1 vote). In fact JTC 1 itself looks likely to experience similar "clogging" because of its increased membership. Indeed, I understand the recent JTC 1 meeting in Brisbane was only quorate (50% rule) because of some late arrivals to the meeting!
Let us hope the new National Bodies discharge their voting responsibilities in future (the situation is gradually improving). If not, I understand the wheels are already in motion to sanction serial offenders by demoting them to observer status within ISO/IEC.
Preparing for Kyoto
The upcoming SC 34 meeting in Kyoto is likely to repeat the pattern of recent meetings, with a large number of attendees hoping to discuss ODF and/or OOXML. Again, they are likely to be disappointed as these topics are not on the agenda (with the exception, perhaps, of Ecma's proposed maintenance agreement for any IS 29500).
It is fair to assume, however, that DIS 29500 will figure in talk in the bars and along the corridors.
One tangential development is that the UK has proposed that a new working group (WG) is established within SC 34 for handling Office document formats. This is a practical proposal to solve the current problem whereby people interested in two distinct areas (DSDL is one; Office formats is the other) have to meet in the same room. Should it happen, the new working group will certainly prove a lively one ...
|
|
2007-10-21, 14:28
Tim Bray's Wide Finder Project has been drawing implementations in a number of language, but none yet in Groovy. Time to put that right …
def hits = [:]
def pat = ~"GET /ongoing/When/\\d{3}x/(\\d{4}/\\d{2}/\\d{2}/[^ .]+) "
new File( args[ 0 ] ).eachLine{ line ->
def matcher = line =~ pat
if( matcher.count ) {
def key = matcher[ 0 ][ 1 ]
def val = hits[ key ]
hits[ key ] = ( val == null ) ? 1 : ++val
}
}
hits.entrySet().sort{ a, b ->
b.value.compareTo( a.value )
}[ 0 .. Math.min( 9, hits.size() - 1 ) ].each{ entry ->
println "$entry.value: $entry.key"
}
Looking at this what's striking is that although Groovy can be written pretty much like full-on prolix Java, it's also possible to write
For benchmarking I stuck together 10,000 copies of Tim's test data to get a log file of approx 1.3 GB. On my humble X31 The original Ruby script gets through this in 92 seconds; Groovy takes 115. Not too shabby. Maybe this is a good excuse to explore how multi-threading would look in Groovy …
I have enjoyed using Ruby and Python in their time, but now that Groovy is here I don't think I'll ever be using them again. It's not so much the terseness which is attractive, but the proper Java underpinning with all those excellent libraries (not least for XML processing) on tap.
|
|
2007-10-21, 12:32 - General
Season of mists and … of geeky types taking pictures of foliage with digital cameras and putting them on their blogs.Here's a couple from Wandlebury.


|

Categories



