On Wed, Mar 06, 2002 at 12:20:02PM -0800, Brian Ingerson wrote:
| > For config files without headers the assumed header could be:
| > --- #YAML:1.0 #TAB:8
| I was half joking about this before, but now I'm very serious.
| For headerless documents, it is up to the application to decide
| the default header (tab behaviour) for the document.
Let's say six months out the Apache group decides to use
YAML. Let's say that someone sets up an Apache server on Linux,
and then a month later, due to corporate policy have to move the
server to WinXP. So, they copy the configuration file over, and
all works well. Then one day, someone loads the configuration
file into Visual Studio to make a change... they make their change
and save it. All hell breaks loose. Why? Beacuse the tabs were
read in as 4 spaces and then were saved as 4 spaces. The distinction
between .... and --------> is now lost, items at the second level of
indentation are now at the first level. Apache e-mail gets a flame
for configuration files that "always break" on Winblows. Apache group
decides that YAML migration wasn't such a great idea afterall.
Would become, if read-in and written out by Visual Studio...
Basically... if the person is _lucky_ the "demotion" of TABS
to 4 spaces will cause a duplicate key, and thus a clear parse
problem. If the person is unlucky this demotion will only happen
in a small area of the file and go un-detected untill a pissed-off
customer calls beacuse their certificate won't be accepted.
The tech-support person will run around with his head cut off
for about a half day, checking the browser, checking the certs,
everything, till he learns that "cert-path" must be a child of
"mod-ssl" and not a sibling. At that point he'll be completely
puzzled how it got demoted. And YAML will get a rightly-deserved
qualification of: "not intutitive".
| This is an excellent compromise. Oren wants seamless interoperability between
| *all* YAML documents, regardless of their domain (intended purpose). Brian
| feels that certain uses (like config files) are securely coupled to their
| applications. So let the application make up the rules. And in the end, the
| user can always override by using #TAB.
This isn't a compromise as it just glosses over the TAB incompatibility
issue. I don't want people to use TABS. TABS are evil since they have
more than one interpretation. However, if someone must absolutely use
TABS, then let's make it BUTT UGLY and very obvious when they do.
Something like #TAB:EVERY-8-COLUMNS or #TAB:TREAT-AS-4-SPACES.
IMHO, #TAB:4 doesn't solve the problem and having it default to
EVERY-8-COLUMNS undermines the whole purpose of #TAB, which is to
make the tab/space mixing policy explicit. An implicit policy is
a non-starter for cross-editor compatibility.
Clark C. Evans Axista, Inc.
XCOLLA Collaborative Project Management Software