On a related note, Mark Alldritt just put up a very good blog post
on the need for a Scripting Interface Design guru to educate
developers about the technology and help them design scripting
interfaces that don't suck:
Well worth a read. (I've already left my own 2c on the subject, of
course.;)
I didn't see it there yet.
However, Scripting Interface Design now presumes an SDEF, so the
first questions should be about the SDEF schema because that now
defines everything.
One might very well ask: "What schema?", because it's only a DTD
right now. As such, there's a couple of loose ends that should be
tied up because DTDs permit stuff that's illegal in XML Schema and
there's a problem with that in sdef.dtd. The effect of dealing with
seemingly insignificant details like this can have a ripple effect
upwards on communicating scripting design. That's because having an
XML Schema will enforce the description to an unambiguous mechanical
sensibility.
Does that sound like a limitation? Well no, not for AppleScript. It
will actually be an enhancement. Take a look at the XML Schema data
types <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#built-in-
datatypes>, and regular expression possibilities <http://www.w3.org/
TR/2004/REC-xmlschema-2-20041028/#regexs> for starters.
When a language can be expressed like that, it follows that the
ensuing implementation, and the possibilities it presents are clear.
Hence explaining scripting interface design will not be limited to
the realm of the guru, but rather more the territory of advanced
users. That is how it should be because it increases the chances that
dictionary designs will be harshly critiqued and from that, better
guidelines evolved.
Beside the gory details though, there's also the question of what the
SDEF DTD->schema doesn't have defined. Like extensibility,
adaptability for other implementations, and annotations (appinfo in
particular). And this last bit should be of some concern for all
those dealing with an AppleScript implementation in their
applications because having it be extensible with room for custom
calls will make things very flexible.
