From: Jason D. <ja...@in...> - 2001-06-20 14:17:14
|
> (1) One evolving spec, with sections becoming "stable"; > (2) A series of related specs. > > Clark favors (1), I favor (2), and it seems Brian favors (2). I'm not > certain what Jason's position is - though we all agree with his point that > we don't want to prematurely freeze specs. Looking at your list below, I'm in the middle. The first three (file format, color idiom, canonical form) should be in the same spec. The APIs should be seperate. > I think that most of the issues can be addressed if we do (2) but > assign the > version number "0.1" to our first release of each. This allows us to start > implementing, but with the warning that 1.0 may be slightly > different. If we > discover we need to change things between "0.1" and "1.0" - to make specs > work together, or just change our minds - we can introduce a > "0.2" version, > etc. Once we have enough of the related specs written, and enough > implementation experience, we'll promote the latest version of > each spec to > "1.0". This means that "1.0" will be, from day one, a set of related and > consistent specs. I like this. > As for the list of specs, Clark's enumeration is a good base. I think we > need something along the lines of: > > - File Format (Intro, Info model, Serialization). > - Color Idiom (Standard colors, perhaps shorthands). > - Canonical Form. > - Incremental API (Language independent, or maybe C). > - Incremental API for language X. > - Native API for language X. > > We can do 0.1 of the first one - file format - right now; this would allow > us to start working on the native APIs for Perl (Data::Denter), > Python, etc. > I think that as a rule, we shouldn't release a spec for an API without a > reference implementation - thoughts? We should have at least _5_ (thinking of all the languages that the four of us know) implementations and a conformance suite. Are we going to be checking these in to CVS on SourceForge under a common license? > > B. Binary vs. Unicode: > > (1) Put it in the information model; > (2) Demote it to a color. > > Clark and Brian favor (1), I favor (2). I've changed my mind to (2) as I think it should be possible to use encodings other than base64. > I'm willing to go with (1). I'll have more to say when we define the > particulars of this color. We have to ensure that "class" > reflects "how will > the object be represented in memory" and "encoding" reflect "how does the > object appear in the YAML file". Otherwise we quickly get into > trouble. One > good example for this is the class "date". It is possible to > "encode" one as > 10-JAN-2001, 01/10/2001, 2001-10-01, etc. But we should follow XML Schema's example and mandate one particular encoding for transfer (ISO 8601). User applications are, of course, free to display it in whatever format they choose. > I agree with Brian, however, that we should keep the definitions > of all the > special colors out of the file format spec. Let's just reserve all > single-indicator-character keys in it and move ahead. I'm not sure if this is a good idea. Think of XML and Namespaces. Since they're divided into two specs, there's two classes of parsers: those that do and those that don't support namespaces. We don't want to have parsers that support the standard colors and those that don't, do we? > C. Shortcut syntax for colors: > > (1) Allow it; > (2) Don't support it. > > Clark favors (1), and so does Jason (I think). Brian and I favor (2). I guess I need to be more clear when I write. I favor (2) but am open to the idea of (1) if you all see fit. My experience with writing an XML parser has really turned me off of special cases in the syntax. > So, quick poll: Should I roll out a "YAML-FILE-FORMAT 0.1 Release > Candidate" > this weekend? (MY fingers are already itching to do it... :-) Yes, please. It shouldn't be too hard to update my C# parser once you do but I'd really like to do some interopability testing with the rest of you. This is where we can start building the set of files that we can use for a conformance suite! Jason. |