***************************** Team Allaire *****************************
I think Emilio has an excellent point--and I think Jeff does too. Having a
definitive standard *is* essential for things like interoperability and
certainly for creating tools that help our work. On the other hand, the
price we pay for those standards is that we are taking a snapshot in
time--and freezing that. We hope that the model we encapsulated at that is
rich and coherent enough to deal with unanticipated needs. When this
happens, it delights us.
On the other hand, here's a case where I clearly did not anticipate a need
that I sure wish I had. It's particularly important that a symbology, which
is a abstracted language of sorts, be rich enough to be able to express true
statements within the realm of that language. The question about how to
express the statement: "I will get one of these options" brings up the
question of how much we want our Fusedoc symbology to do.
John Quarto vonTivadar (whom I officially dub "Q" henceforth) asks the
question, "OK, if Fusedoc should be able to express that statement, how
about some others that are related?" Q suggests that we shouldn't try to
make Fusedoc do too much or we'll end up with a symbol language that's too
hard to learn and remember.
I'm certainly sympathetic to that argument--I learned an important watching
simpler protocols succeed where CORBA largely failed. On the other hand, not
being able to express the above statement does seem a pretty serious
failing. I'd like to ask you all to suggest some statements that you think
Fusedoc should encompass. If you could put them in a simple form like:
if i get a then i will also get b
or
if the value of fuseaction is "XFA.onSubmitForm" I set client.CurrentUser;
otherwise I set client.Unregistered.
(BTW, I'm not at all sure that Fusedoc should be able to handle either of
those; I'm just using them because I can't think of anything better right
now.)
If you have ideas about this, I'd really like to hear them. Folks like Jeff
really do need to know that a standard exists. We have one right now that's
maybe version 1. What should version 2 do different--if anything?
Hal
-----Original Message-----
From: Emilio [mailto:[EMAIL PROTECTED]]
Sent: Saturday, May 26, 2001 1:51 PM
To: Fusebox
Subject: RE: Fusedocs Q
Jeff:
I think we need to keep in mind that we are sharing ideas and opinions not
truths. By saying that Hal's ideas are the "authority" you not only prevent
new ideas and techniques from entering the standards, but you prevent Hal's
own idea/opinions from evolving, which I would say is what got many of our
techniques to where they are today.
As soon as the "word" becomes more Holy than the meaning, you've got off the
boat.
I think everyone's contributions and feelings of community are what should
be the authority, not the current state of what we think is right, as we all
know that changes with the rise and fall of technology.
<snip>
Very well, I will therefore create a new version of Harness with the extra
parsing required to handle the mutually-exclusive notation. And Hal, try to
get some of the grime off that crystal ball so this doesn't happen again,
huh?
;>
</snip>
that was ouch! Plus I missed out on the clairvoyance class everyone has
been attending so I wouldn't be able to live up to that last request.
my 2 bitz
Emilio
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
