Your country's comments rated!

by Rick Jelliffe

I've just glanced over the 3549 or so comments put in by various national bodies for the recent ballot on DIS 29500. I've made a table listing the countries that commented, together with their votes and whether I think most of their issues could be resolved during the upcoming Ballot Resolution Meeting next year.

The bottom line: there are a few touchstone issues that may be tricky but it is difficult to see from the comments that DIS 29500 would not be successfully fixed and approved to be an ISO standard. The particular touchstone issues I see are that spreadsheet dates need to be able to go before 1900, that DEVMODE issues need to be worked through more, that the retirement of VML needs to be handled now, and that there needs to be a better story for MathML.

Apart from these, there is a sea of details that are eminently fixable: typos, clarifications, fixing schemas against closed lists, the use of more standard notations for fields, encryption, conformance language, refactoring the spec: editorial and syntactic rather than data model or wholesale semantic changes. On the other extreme, there are various non-starters which I expect have little hope since they run counter to the rationale for the spec: adopting SVG or adding various frustrating little things in the name of compatibility with ODF (Some NBs even call for ODF's blink element, even though blink has been removed from HTML since it can cause epileptic fits!)

You can find a full list of national votes from the SC34 website. I was pleased to see that all the issues I raised ended up in Standards Australia's comments (it abstained on the vote, but its comments still go in the mix.)

What is in the table



The thing that interested me in this table was whether I thought each National Body's comments could be resolved enough to change their No vote to Yes vote. I am assuming there is no point to a standard that Ecma and Microsoft could not buy into. One of most interesting documents in the collection of comments from different bodies is Ecma's own contribution: basically they accept almost all of Japan's technical issues (which have a lot of overlap) which augers well for many of the other changes.

So I provide a rating as to whether I expect that a National Body's vote will be definitely no, probably no, or probably will change to yes as a result of a successful BRM. Caveat: The NB comments do provide a much clearer indication of each National Body's thinking than just the raw Yes/No/Abstain vote (which are utterly useless in predicting a finally outcome); however, I would be a little more confident in my ratings of the NBs if SC34 or ISO had released information about which NBs had ticked the normal box that says they might change their mind if the issues were resolved. I guess you would rate me as an optimist in general about the process, but still I am not saying that all these NBs will necessarily vote yes ultimately; but there is quite a bit of commonality to the comments.

I also have columns marked "Indie" which has an X if it seems the NB undertook independent review of the specification. And one marked "Parrot" where the NB is reproducing (perhaps with some localization or sorting or selection) the material, turning the standards review process into a form-letter campaign. I have mixed feelings about parrot items: on the one hand an NB is free to consider whatever issues it likes, and some NBs have procedures that may favour the garrulous, but on the other hand it represents a hijacking of valuable review time to obsess on the same issues, rather than give fresh eyes.

The reviews that seem to me the best are those where an NB focuses on its areas of expertise or national interest: Japan is very interested in schemas, Israel is very interested in right-to-left text, Ireland is very interested in correct references, Australia is very interested in clarity, Canada is very interested in assistive technology, Tunisia is interested in the application to mobile devices, Ghana (with a large Arabic influence) is interested in IRIs, and so on. The comments that seem least useful are the parrot comments, and the ones with vague recommendations. (I expect that this is the first comments that many of the NB committees or staff have sent in, so it is a good training exercise nonetheless.)

And there are some nice touches in there, where perhaps some cultural values slip through: Switzerland's comments are a list of problems they actually have rejected and the details why, and Jordan and Turkey both have dignified documents that explain their positive reasons. Some of the parroted comments are unnecessarily ranty, but only a few were mad: the US comments in one place want to remove OPC because it is not present in the "pre-existing binary format" but then they want to get rid of compatability elenents because they are a "museum":..they don't need to worry about consistency because they are voting yes anyway: some of the comments are like that, they are there to only allow the cake to be had and eaten. I expect that several NBs are not really attached to some of their comments.

The second last column is "Off-topic" which is where the NB's comments includes material that the BRM cannot discuss. These are typically issues concerning IPR. MS needs to spend a bit more effort on this: Switzerland's comment is really interesting on this point.

The final column marked "radical" is where a National Body's comments include something that I think will be a challenge for MS or Ecma or ISO to support. I don't include things like changing minor notations or providing better text explanations for things: I think the Ecma comments show a willingness to have those. However, where some change involves a wholesale alteration of the technology or its implementation, I would be surprised if it were acceptable. This is because for every nation that is voting "No" because they really prefer ODF, etc, there are two who are voting in favour because OOXML is what it is.







































































































































































































































































































































































































































































































































Country



Vote



Really No?




Probably No?



Probably Yes?




Indie



Parrot



Off-topic material




Radical



Australia




Abstain



-




-



-



X




 



X




 



Austria




Yes



 



 



(X)



 



 




X



 



Brazil



No




 





X



 



X



 




 



Bulgaria




Yes



 




 



(X)



 



 



X



 




Canada



No




 



 



X




X



X




 



Use DrawingML rather than VML




Chile



Abstain



-




-



-




 



X



 



Field formatting.


Use MathML, Use SMIL, Use SVG, Use ODF



China




No



X




 



 



 




 



 



Review time



(Document 13)



?



 



 



X?




 



 



 




Remove VML



Colombia




Yes



 




 



(X)



 



 



 



OPC to separate standard




Czech Republic



No




 



 



X




X



 




X



 




Denmark



No



 



 



X



X




 



X




 



Finland




Abstain



-



-




-



 




 



 



Dates before 1900. Remove VML. Use MathML



France



No



 





X




X



X




X



Date prior 1900, remove math pending mathml3




Germany



Yes



 



 



(X)



X




X



 




Dates prior to 1900



Ghana




Yes



 



 



(X)



X



X




 



Dates prior to 1900. (replace VML with DrawingML, adopt MathML)



Great Britain



No




 



X



 



X



X



 




Add ODF-isms, (replace VML with DrawingML, adopt MathML)



Greece




Yes



 




 



(X)



 



 



X



Dates prior to 1900, (replace VML with DrawingML, adopt MathML)




India



No




 



 



X




 



X




X



Use MathML, pre 1900 dates




Iran



No



 



 



X



 




X



X




Dates before 1900. Add ODF-isms



Ireland




No



 



 



X



X



 




 



Dates before 1900



Israel



Abstain




-



-



-




X



 




 



 



Italy




Abstain



-




-



-



 



 



 



Reference implementation, test suite




Japan



No




 



 



X




X



 




 



Publish OPC as separate standard




Kenya



Yes



 



 



(X)



 




X



X




Dates before 1900. Remove DrawingML



Korea




No



 



X



 



 



X




 



Needs interoperability with ODF. Remove VML and DrawingML



Malta



Yes




 



 



X



 



 



 



 



Mexico



Abstain



-



-




-



 




 



 



Dates before 1900



New Zealand



No



 



X



 




 



X




X



Rename elements,


vague



Norway



No




 



 



X



 



 



 



Split out DrawingML. Split out OPC



Peru



Abstain



-



-




-



 




 



 



Dates before 1900



Philippines



No



 



 



X




 



 



 




Dates before 1900



Poland




Yes



 




 



(X)



 



 



 



 



Portugal



Yes



 



 



(X)




X



X




X



 




Singapore



Yes



 



 



(X)



 




 



 



 




South Africa



No




X



 




 



 



 




X



Rewrite based on ODF. Make OPC a separate standard. Remove DrawingML
and MathML




Switzerland



Yes



 



 



(X)



 




 



 



Dates before 1900




Thailand



No




X



 




 



 



 




 



Time for review




Tunisia



Yes



 



 



(X)



X




 



 



 




Turkey



Yes




 



 



(X)




 



 



 




 



US




Yes



 




 



(X)



X



 



 



X remove VML, Drawing ML, OPC, compatibility, dates before 1900




Uruguay



Yes




 



 



(X)




 



X




 



(replace VML with DrawingML, adopt MathML)




Venezuela



Yes



 



 



(X)



 




X



 




 



35 Comments

stelt
2007-09-13 11:12:40
that's 9 times "get rid of VML" !!
A.Falk
2007-09-13 13:41:25
Great table, thanks!
len
2007-09-13 14:35:08
Getting rid of VML is harder than you think. In terms of a namespaced component in the browser, it works and is much more widely fielded than SVG at this time. This is hard. When you want to break up something like OOXML or move ODF and OOXML to a shared center, you have to work out the commonalities before you start dropping big pieces of functionality.
anon
2007-09-13 20:28:34
Are the comments available publically? I'd love to read more details about these countries' areas of expertise and the Swiss comments about IP. Can you please provide pointers?
Rick Jelliffe
2007-09-13 22:27:56
stelt: Yes. But actually only two countries who have noes that could convert to yesses suggest it. For the others, it is not important to them just a nice idea.


The other aspect to this is that MS itself is removing VML from Office: they just didn't around to doing it everywhere yet. So this is a good chance for MS to cooperate with Ecma and for Ecma to cooperate with the NBs to get something that would be win/win. (At a certain point it becomes more valuable PR for MS to say "We changed OOXML in response: it really is open" rather than the PR benefit of saying "Office 2007 follows the Ecma standard": the later would tend to retard their happiness for progress.)


It is a big mistake to think that many of the NB changes are things that MS might not itself see as good things! For example, where there are fixed lists in the schema, these tend to tie the schema to a particular version of the product and therefore create a maintenance problem: undoubtedly MS will be having extra ideas for OOXML coming in from the Mac port and from ports by other vendors, and undoubtedly from localization too. Changing fixed lists to open lists (e.g. less enumerations, more simple tokens) reduces the validation power of the schema (which can be addressed by using derived schemas for a product) but increases the flexibility where MS can evolve Office.


I expect the realistic resolution would be to move VML to a non-normative annex, and generalize where it is used so that multiple formats are possible, with DrawingML and VML being the ones that MS chooses to implement. So that nominally SVG could be used, but anyone who wanted actual interoperability would choose DrawingML. Or VML could be complete removed from DIS 29500 but still allowed by a conforming implementation.


That solution doesn't invalidate any existing Office 2007 documents, doesn't make a deprecated language part of the normative standard, still documents VML, allows MS to retire VML from future versions of Office, and would allow other graphics formats to be used if there is some market requirement (e.g. if governments say "Drawings in SVG must be allowed").


Those are the kinds of trade-off that I expect would be well considered by NBs in advance of the BRM and at the BRM. Other possibilities and ideas should come up too of course. But I have said it a million times already, the idea will be win/win: NBs happy, Ecma happy. The BRM is there to try to negotiate making as many people happy, and even to make grumpy NBs less grumpy, so that they will think "We still cannot support this because of reasons A, B and C but it is good that D, E amd F have been fixed."


I think it is always good for standards to have open lists: plurality has lots of evolution and growth benefits at the expense of the advantage of fixed lists where interopability can be "guaranteed".

Rick Jelliffe
2007-09-13 22:43:48
Anon: Sorry not to give a link.


You can find the link on Alex Brown's blog. I am giving his page rather the link directly, because he has a different perspective.


The big thing, of course, is to read the countries vote before reading the comments. Sometimes NBs just send on all the comments they think are relevant even if they were not convincing to the NB: so a country can vote yes, but have quite ranty or radical comments that don't actually have consensus at the NB. I think this is really slack myself, but the level of heat is causing it: the BRM will be very aware that the radical issues that yes-voting NBs raise are not being presented by the NB as must-haves.

len
2007-09-14 06:02:20
In the Office distribution, perhaps, but the VML dll ships with the browsers and gets used a lot. It is harder than people want to admit to start teasing those namespaced components out of the apps and vector graphics is one of the toughest ones. I do agree with the non-normative part.


At this point, they seem to be moving away from that kind of component, however, and moving into Silverlight/XAML. Again, one has to stop looking exclusively at office documents which are fast becoming dodos, and look at the interactive apps where information is rendered into dashboard widgets and eventually these become map layers in a higher dimensional display system such as the virtual earth systems emerging. Now the namespace dominance implodes and the text/data portions are wrapped in the graphics portion as a map layer.


The hard trick for standards building is to precisely target their effective time of governance before they should be retired.

hAl
2007-09-14 06:10:29
I wonder why an ISO national body would prefer MathML over Office Open XML Math (OMML).
OMML is fully compatible with MathML trough a relatively simple XSLT conversion mechanisn but also have the added advantage of integrating with Office wordprocessing features like notes/annotations and revision marking which MathML can't because MathML seems more for presentation than for editting.


It seems strange that an ISO national body would recommend using a non-ISO standard that is more limited than a proposed format which could be part of ISO standards.

hAl
2007-09-14 06:13:07
Great Britain seems to have send in the most comments. How can they be rated as parrot only. Are you sure you have not mixed up column names ?
Rick Jelliffe
2007-09-14 08:17:27
hAl: I give UK checks in both the 'Indie' and 'Parrot' columns, they are not mutually exclusive. Certainly for SC34 WG1, I think the UK and Japan NBs pride themselves on their thorough reviews, which makes them such key players at SC34.


On the issue of MathML, I think originally it actually contains two languages: one is a presentation-based language and the other is a semantic based one (think Mathematica). And within formulae there are lots of sub-domains (specialist mathematics and so on) that make it quite tricky to capture things adequately for everyone. And the needs of laymen and students may be different from the needs of professional mathematicians and quality typesetters. Plus it is a notoriously conservative trade, so people who start off in TeX don't see any value in changing. It is not an area of typesetting I would take sides on without a lot more study.


What I would say is that I think we can adopt a four-layer view of documents: the bottom layer is field notations, such as ISO 8601, which are usually in attribute values; the second layer is in utility namespaces, such as XLink and Dublin Core, which provide very simple capabilities for all sorts of applications; the third is in topical namespaces, which provide information from a certain angle, such as MathML does for mathematics; and the top level are the application formats.


I think the underlying challenge of the BRM is to come to grips with what the preferred practice should be for each layer: I see three choices, each with pros and cons:


* One open standard option for each layer: I think this is the view that Tim Bray has pretty consistently articulated in many instances over the years: so you don't need JSON when you have XML;


* A couple of standard families, where each family may be tightly coupled but no interbreeding between the races is tolerated: I think this is the position that both ODF and MS have taken in the past.


* Systematic plurality, where each layer allows choice in the successive layers: this is what I have been calling for over most of the last decade. So the question is not XML or JSON, but whether the infrastructure supports them both well to allow developers to choose the appropriate one.


Applying these three views to MathML, I think the single-standards people would say "It is a no-brainer: of course OOXML should drop its own maths and adopt the standard MathML"; the keep-it-in-the-family mob would say "They should do what they do best and we should do what we do best, and they should not be forced to support how we think and we should not be forced to support how they think, and the consumer has nice clear choice between Pepsi and Coke"; the pluralist would say, "what matters is that the framework allows both MathML and the OOXML Math to be provided, perhaps even both at the same time!"


None of these three positions is intrinsically (and certainly not morally) wrong, but I don't think there will ever be agreement on which is best because I think they come from fairly deep things hard-wired into people's brains.


If you look at the comments on my blog over the last year, you will regularly people saying "It goes without saying that the point of standards is to have only one" or "I don't see the need for standards, everyone can do their own thing" or "Let the market decide and don't get in the way of innovation": the three tendencies!


So, naturally as a plurality, my POV is that it would be a great result if OOXML was checked to make sure that it could handle a switch to, say, the future MathML 3 without change. And indeed to handle specialist Math languages from other vendors alongside Office's native one or MathML as well. That is one reason I am keen on OPC: I think it is a good step in the right direction for supporting plurality.


If you look at the way that email handles HTML mail, as a multipart message with a plain text part and an HTML part, so that the client mail reader can choose the one, that is exactly the pluralist kind of solution.


Once you are aware of this aesthetic-psychological preference that people have, it becomes easier to figure what they think about standards.


As a pluralist, when I think of standards, I think about things like MIME content types and the TCP/IP tree and even XML extensibility as the main game, while particular content types or protocols or schemas are just the decorations on the Christmas tree. A single-standard person would look at them and say "there is only one syntax for content types, only one syntax for XML WF, and in fact TCP/IP are tightly coupled" and feel that the sharp end of the sword was the fixity not the extensibility. Of course, I am stereotyping!

Rick Jelliffe
2007-09-14 08:21:42
Len: Sure, but removing VML from the standard does not mean erasing it from history, or saying that documents that use VML do not thereby conform to Office Open XML. The issue of the particular drawing formats to use would be a profile issue, not a standards one.


Kurt Cagle
2007-09-14 16:00:43
Rick,


I applaud your suggestion for the removal of any drawing specification from the OOXML document with an eye towards maintaining it as a distinct module. While it is possible that Microsoft may actually implement SVG, it is, as you point out, unlikely, and I feel that DrawingML adoption is similarly a non-start for Microsoft.


One of my contentions against OOXML as a standard in the first place was the fact that it represented not one standard but a number of them, including a drawing module, a math module and so forth, each of which has its own inherent taxonomy. Perhaps one approach that I think would placate those of us on the other side of the OOXML divide would be for Microsoft to recognize where the natural modularization points within their proposed specification are and 1) provide separate modular specifications for each of these subschemas, 2) provide a reasonable extension mechanism such that other OOXML implementations could integrate their own modules into the larger OOXML framework. I see that as a potential win for both sides, as it gives Microsoft an excuse for providing a good faith effort on making the standard "open" while at the same time not significantly compromising upon their already significant investment in the proposed standard (or its underlying technology), while from the standpoint of competitors and the open source market such an effort makes it possible to implement non-MS OOXML systems that nonetheless take advantage of native open standards components such as SVG, XForms, and so on.

Rick Jelliffe
2007-09-14 22:17:23
Kurt: In my three personality-type model, sometimes the technology clearly favours the approach of one personality-type and other times favours another personality-type. That is why one never group can never win.


For example, in the case of maths modules, it seems that there is a high degree of dispute which suggests that the pluralist approach is appropriate. But Math models (like tables and graphics) may have generic text in them, in which case you probably have to tightly couple the implementation of the equations with the typesetting system, which favours the multiple-independent traditions viewpoint. But text is highly generic and has many commonalities, which favours the single standard viewpoint. And text can contain graphics which favours the pluralist viewpoint. And so it goes. (None of the views is universally wrong unless they deny the other: but as a pluralist I suppose I would feel that whether it was right or wrong!)


In any case, my suggestion is only that the BRM checks that the graphics is indeed substitutable: I don't see any particular benefit in removing VML and DrawingML, given the goals of the spec. In the back of my mind I have an idea from somewhere that actually there is a difference between what Office can accept and what it generates: DIS 29500 obviously needs to follow what it can (and will in the near term) accept (i.e. not the subset of what it generates.)


I think it would be quite difficult to get rid of DrawingML and keep either PresentationML or SpreadsheetML, since both are thoroughly based on DrawingML, for example charting in Speadsheet ML. So that is why I don't include it as a touchstone issue. VML is a sitting duck.


On the issue of modularity, actually there is a high degree of modularity at the part level: parts have relationship types that are independent of their schema so it is possible at the OPC level to have substitute (and sometimes multiple) alternate parts for the same relationship type (e.g. styles, or graphics). It is inside a particular part where there is usually no flexibility: the modularity is not of arbitrary grain but of the granularity of the OPC part. (Now there are a few other exceptions to this, but they are exceptions.)


One way the standard could be substantially improved would be a clearer organization of the text against all the different namespaces, in particular to make it clear which where the real modularity (i.e. alternative/substitutable OPC parts) occurs and where a namespace is just a change in vocabulary but is not substitutable.


(<rant>These kinds of issues are the things that NBs should have been looking at in their own independent reviews rather than dancing a panic-ridden tarantella to the piper's tune. Rather than just stopping at 'I think modularity is important' but actually figuring out some concrete proposal. But there still is five months, plenty of time.</rant>)

hAl
2007-09-15 02:13:57
hAl: I give UK checks in both the 'Indie' and 'Parrot' columns, they are not mutually exclusive.


Then your table is screwed in both IE6 and IE7 because it definitly does not look that way to me.

Rick Jelliffe
2007-09-15 21:33:17
HAl: Yikes, the table was badly screwed in IE due to a markup error. (Firefox is cool with <p '> and just ignores the ', but IE seems to leave out a larger chunk.) In the end there was a heading missing so the columns appeared transposed.


I've fixed it now. Thanks for the alert and apologies to IE users!

len
2007-09-17 05:56:56
I have a suggestion for that, Rick. Companies that support a file format then find it deprecated should make the dll available for free distribution from any site that still uses it. In the case of VML, no big deal as long as the interface is supported.


When I released River of Life last week, I did it knowing that realistically only one VRML/X3D browser can support worlds at that complexity level: BS Contact. Irritatingly, we realized the new version dropped support for gif animation which plays a major role in that world. Can it be replaced by another format? Not cheaply. Do I still have the version that works with it? Yes, of course. Can I put that version up on my own site for others to download? Dubious legally.


Interactive complex content becomes more the norm now that the web is an entertainment medium. This is a bifurcating point for the standards practices because where once office documents were a main focus for web formats and the most complex, that is shifting toward the integrated hypermedia formats where there are different wrappers (outer docs). Suddenly losing one of the inner document types after relying on it for an expensive project (or one that takes a long time to build) can be disastrous. A practice that says 'sure, we won't work on it, but here is the open source or here is the distro for free for your site' would help.

bert
2007-09-18 15:50:48
"And there are some nice touches in there, where perhaps some cultural values slip through: Switzerland’s comments are a list of problems they actually have rejected and the details why,"


Well, it shows the unfair bias of the chair.



"and Jordan and Turkey both have dignified documents that explain their positive reasons."


Shodder! Jordan and Turkey need to be told how the standard process works.


"Some of the parroted comments are unnecessarily ranty, but only a few were mad: the US comments in one place want to remove OPC because it is not present in the “pre-existing binary format”"


The OPC is a design problem because it makes the format artificially incompatible with ISO 26300 and does not further the goal of backwards compatibility with existing formats.


"but then they want to get rid of compatability elenents because they are a “museum”:..they don’t need to worry about consistency because they are voting yes anyway:"


You know very well, why they did.


"some of the comments are like that, they are there to only allow the cake to be had and eaten. I expect that several NBs are not really attached to some of their comments."


It seems to me that members are now waking up and prepare to fight back.

Rick Jelliffe
2007-09-18 18:57:20
Bert: How files are arranged has nothing inside the ZIP archive has absolutely nothing to do with the goal of preserving legacy information. Files need to be arranged some way. Furthermore, the idea that OOXML's only goal is legacy is rubbish: read the Part 1 Introduction. (Small files with indirection clearly aids the goal of (which is to "enable ...implementation") because it allows update by substituting parts without requiring rewrites of references.


In fact, OPC largely recreates the entity mechanism of IS8879 that XML simplified out. SC34 has long been a supporter of indirection mechanisms and linking, notably IS10747. In fact, there was even a comment that OPC should become a separately numbered standard because it was useful (and being part of IS29500 would make it difficult for some people to use without losing face, I suppose.)


The standardization problems that I see with OPC are first that ZIP is not a standard (ODF has same issue of course) and second that it would have been better for them to use XLink or Topic Maps or RDF for the syntax of the relationship files: but these is a minor issue.

Matthew Cruickshank
2007-09-19 18:27:48
Hi Rick, regarding the blink tag and epileptic fits...


I think it's important to say that blinking doesn't inherently cause epileptic fits... it's all to do with the pacing of the blink. An "On/Off" cycle can causes fits, whereas a MilSpec cycle of "On/On/Off" will not cause fits, and since the era of Netscape 2 (I think) browsers have not used On/Off pacing.


Blinking text itself is used in The Real World (eg, road works signs) and I think it should be considered like any other animation. When used sparingly animation can be useful, but when used indiscriminately it causes problems.


I've infrequently used blinking text on webpages to grab attention (a webapp security system to do with open doors after hours!)

Rick Jelliffe
2007-09-19 19:14:12
Matthew: Good points. I suppose there is scope to even say that Blink is good if it has a safe semantic and prevents home made versions of blink made with SMIL that are unsafe. (But it doesn't belong in a base text package for any system.)


The current draft of the WAI has the latest thinking on this, and I see it is above three times a second that is dangerous:
http://www.w3.org/WAI/GL/WCAG20/#seizure


Three Flashes or Below Threshold: Content does not contain anything that flashes more than three times in any one second period, or the flash is below the general flash and red flash thresholds.


So they say don't blink for more than three seconds unless you have taken all these rates into consideration.


Content does not blink for more than three seconds, or a method is available to stop all blinking content in the Web page.


general flash and red flash thresholds


a sequence of flashes or rapidly changing image sequences where all three of the following occur:


1 there are more than three flashes within any one-second period; and
2.the flashing is below 50 Hz; and
3. the combined area of flashes occurring concurrently and contiguously occupies more than a total of .006 steradians (25% of any 10 degree visual field on the screen).


For the general flash threshold, a flash is defined as a pair of opposing changes in relative luminance of 10% or more and the relative luminance of the darker image is below 0.80. An "opposing change" is an increase followed by a decrease, or a decrease followed by an increase.


For the red flash threshold, a flash is defined as any transition to or from a saturated red.

Rick Jelliffe
2007-09-20 00:57:17
And I see Matthew has a fun page up at
www.iso-vote.com
John Drinkwater
2007-09-20 06:34:18
You seem to not understand the difference between GB and UK, they are not the same thing. In the table you have done this; please fix it
Rick Jelliffe
2007-09-20 09:02:37
John: When they change their ISO country code from GB to UK I will happily change the entry :-)


If we are being exact, it is neither GB nor UK but BSI, originally an engineering committee that was granted a Royal Charter and not an organ of government AFAIK. People don't know the initials of the various National Bodies, so I put "Country" with the name that I thought would be most well-known to the widest number of readers, not to reunify of Ireland by stealth.

Dave
2007-09-20 12:44:23
As one who is interested in XML-based graphics handling, I noticed the reference to VML, so I read further and found comments about the relationships to SVG and "DrawingML."

To me it is disconcerting that the OOXML seems to call for (a) either retention or deprecation of "VML" I can't tell which is probable, (b) non-support or compartmentalization of "SVG," and (c) introduction of yet another graphics dialect "DrawingML" that is interlinked with other OOXML elements such as "SpreadsheetML" and "PresentationML." Another wild rumor in this space is the idea that Microsoft Silverlight plug-in could end up supporting SVG, or maybe it won't.

The apparent and continuing balkanization of "basic" graphics standards in the VML / SVG / DrawingML / Silverlight / Flash areas is sure a messy spectacle. Plenty of risk and false starts for anyone trying to use them while retaining some degree of platform independence.

If OOXML gets traction, I suppose graphics developers must then eagerly await when / if other vendors like Firefox or Opera or Adobe begin to support it. A probable long road with a lot of non-interoperability during the journey.
Rick Jelliffe
2007-09-21 00:18:01
Dave: It is trite to say it, but some differences between markup languages are trivial and some are complex; and some are unreconilable. And similarly given any existing implementation of some application, supporting a markup language will involve some trivial issues, some complex, and some things may be unreconcilable.


So it is glib to say "Adopt SVG rather than DrawingML" as if it can be done just by clicking fingers (I am sure you weren't quite saying that!) SVG was created in part as a response to VML. And DrawingML was created in part as a response to VML and to SVG.


The trouble with saying "Go standards" is that it is legitimate for a company to want to support a different feature set than the one the standard supports. Just as it is legimate for customers to reject applications that go beyond the standard set of features.

Wouter
2007-09-22 01:01:25
Rick,


the Netherlands is missing from the table.


Wouter

Rick Jelliffe
2007-09-23 00:22:15
Wouter: I did not see any Dutch comments in the ZIP archive. There is a comments document J1N8726-13 which does not have a country code on it: is that The Netherlands?
hAl
2007-09-23 07:26:59
I think the Netherlands that abstained have not send in comments
hAl
2007-09-26 10:55:38
After exameming several hundred comments on
www.dis29550.org
I have found that in some of the most duplicated comments you can compress about 300 comments to about 8-10.
The US, UK ,France and Chile have the most eleborate way to raise issues and add and issue for every instance they find of a certain issue. That leads to the exteme case that this single issue:
http://www.dis29500.org/ecma-28/
has about almost instances in the national bodies comments.
Rick Jelliffe
2007-09-26 15:47:56
hAl: How many instances?


I can understand the Australian position (only new local comments) or the UK position (get everything on the table) but I think the countries who merely repeated an externally-fed list of objections word-for-word or idea-for-idea have pretty much failed in their review obligations and wasted the opportunity.

hAl
2007-09-27 02:33:05
Oops, sorry
Almost 100 seperate comments on the issue raised in
http://www.dis29500.org/ecma-28/
hAl
2007-10-01 05:25:12
I have now examined (quick check and not in dept) nearly a thousand comments on www.dis29500.org.
Based on that I would think the 3500 comments are actually comprising about 500-1000 seperate issues with the rest being either identical duplicates or multiple instances of the same issue.
Most of the issues are editorial in nature.


There are quite a few what I consider to be unsolvables issues suggesting radical changes to the spec, removal of either entire markup languagues or entire parts of the spec or changing the fasttrack procedure.
There are also quite a few silly issues like having 40-50 comment instances complaining that the zipped schema annexes are not in a humanly readable format. Quite amusing from a bunch of countries that a year ago approved a document format based on zip packages.


Or my favorite the US comment that states the Open packaging convention needs to be stricken from the standard because it has capabilities that were not present in the previous binaries formats.


Most duplicates found so far are the the above mentioned comment on the "x-bar is the mean" (or whatever) and the comments on legacy compatibility tags with 5-6 countries making a comment for individual legacy tags.


I expect about 60-80% of the issues to be solved upfront because they are realtivly easily solvable. There is also a decent amount of comments that do not require solving. About 5-10% of the issues looks unsolvable in the current ballot resolution phase. About 50 issues are moderatly to difficult to solve issues. Difficult because either time constraints or the impact on the format specification or even because of the varying views by the ISO members

Rick Jelliffe
2007-10-01 19:15:52
hAl: XML being non readable by humans is something I wrote about in a previous blog. I don't get it. Still no-one has been able to state what the problem is. The trouble seems to be that XML is not readable by parrots.


(Parrots also have a digestive problem: they regurgitate what they have been spoonfed!)


Certainly if you get rid of duplicates you will come to less than a thousand; but if you then categorize them by class or according to principle you end up with only a few score problems (e.g. typos, grammar, error, lack of openness.)


If we are lucky, the BRM may in fact identify more problems than in the ballot issues: once the ballot issues are categorized into sui generis heads, other examples that come up can be dealt with too, as part of the same comment.


The ballot issues are MacGuffins: they are the excuses for the action. The formal procedures certainly revolve around them, but it happen in the wider and over-arching reason for the BRM--to get the most agreement on the best spec given the constraints of fast-tracking.

Roozbeh Pournader
2007-10-03 03:07:13
You missed some of the local taste of Iran's comments. Their first few comments are about adding support for the Persian calendar.
RIck Jelliffe
2007-10-03 04:00:34
Roozbeh: I thought Iran's comments were interesting, mature and competent. I hope they can participate more: all the international political complications of the current time add impediments to a process that is essentially apolitical and cooperative. In 2000 I spoke at an XML Conference in San Jose, where my topic was the need for thorough internationalization of standards as a mechanism to make sure that developing nations, especially those with communities with anti-Western views, were treated fairly. I see Andy Updegrove has some material of related interest this month that is well worth reading. (Though I think his emphasis on neo-colonialism perhaps panders to jingoism a little: globalization has many different characteristics to colonization. Certainly not all globalization involves neo-colonization.)


The issue of national date formats is one of the big objections I had to W3C XML Schemas. The rest of the XSD working group did not buy my argument that what was important in markup is not to have a single unified international format (and leave rendering it in localized forms to applications) but that real local data could be marked up (notations!) and mapped to some local forms.


This approach is the one adopted by ISO DSDL's Data Type Library Language (DSDL part 4, now in committee draft). In future standards that adopt ISO DSDL (RELAX NG, NVRL, Schematron, DTTL, DSRL) there will be much greater capability to express and validate localized markup (localized element names and values too!).


So allowing localized date formats into an XSD (or RELAX NG or DTD) schema at the current time unfortunately means that the data will not be validated. This is a step backwards for rigorous markup, but may still be worthwhile doing anyway.


There is a balance between ease of use and ease of implementation: localized forms make it easy if the data is your region's form, but make it hard if you have to support multiple region's forms. My personal opinion is that ISO DTTL provides the way out, because the rules can be expressed declaratively in an executable form, which reduce the programming effort.


Some of the parroted comments from NBs about the "Gregorian Calendar" are a little problematic, given that the international standard is ISO8601 and the XSD uses ISO8601. I would expect that ISO 8601 would be maintained as the date format, but that spreadsheet functions will be vetted to make sure that localized date formats are properly supported. There are some standards that may help here (ISO HyTime, ISO DSDL, ISO POSIX, ISO ODF) with mappings or functions.


I think that one thing that will come out from the BRM phase is a greater realization of the enormous gaps in standardization that exist. What is the international standard for Persian calendar? Is there an English or French language translation suitable for inclusion in an ISO standard or even technical report? The trouble is that it may be true that DIS 29500 and IS 26300 should include detailed information on regional and national calendars, however, it may be that DIS 29500 and IS26300 are not the places for this information: the information may belong in a different standard, perhaps not in the perview of JTC1 SC34 even. Some issues may have to be resolved by the NB saying "Oh, we need the chicken before the egg: we need to set up a separate process for this other standard, and then in a later revision to DIS 29500 make specific reference". In which case the job of the editor becomes making sure that the text of IS29500 is future-proofed to allow future advances in standardization to be adopted with minimal effort.