rc3.org Strong opinions weakly held

The tendency of the tech press and analysts to reward companies for making announcements but not ship what they demonstrated or take years to ship is an ongoing frustration of mine. I really dislike the distortion of competition, “Well, based on the spec, this is going to be so much better than $product when it ships in $n months!”

That and those anointing any comer as “$product killer” tend to presume that the manufacturer of $product is going to stand still and take it.

Posted by Nathan L. Walls on 13 July 2010 @ 10pm

Thanks for the link! I am just getting the hang of it over there… frequent commenter there, but actually blogging is hard. Who knew? Oh wait, you knew.

The examples versus formats thing for dates is quite similar the point I have been trying to make for years with regards to schema languages. If you want people to use a schema language, you need to make the schema objects LOOK JUST LIKE the instance objects they will validate. The people who need to write schemas are domain experts, not programming experts. They can probably learn your simple key-value type format (JSON, simple XML, properties files, whatever). But WHY would you make them learn a whole other language and technology set just to write down what they want to say?

The current version of the JSON schema language I wrote (which is still a draft… the validator which our awesome summer intern wrote is waiting for the next release) doesn’t actually let you supply an instance object as a schema. But it’s pretty damn close.

Posted by Jacob Davies on 14 July 2010 @ 2pm

In some cases (like dates) examples as format definitions don’t work well because there can be ambiguity. “Monday 12 July 2010 02:30PM” is easy. What about the date string “10/10/10″? Which field is which? It depends on your preference, locale, or other requirements. I’ve worked on systems where that date string could be “Year/Month/Day”, “Day/Month/Year” and “Month/Day/Year”.

If you use a format that is more obvious to the user, like “Day/Month/Year” aren’t you going to end up with format definitions that include values like “Day-With-Leading-Zero/Month-With-Leading-Zero/Two-Digit-Year” to cover all the variants? That’s more readable than “%d/%m/%y” (yes, I had to look that up), but I suspect I’d have to look up the syntax in both cases.

Posted by John on 15 July 2010 @ 12am

If I were creating a Web application that generated the dates, I could just add a validator that flagged ambiguity. For example, if you entered, 10/10/10, it could ask you to use values that do not overlap. So they could enter 12/25/99 instead.

Posted by Rafe on 15 July 2010 @ 9am