Re: Scripting Interface Design
Re: Scripting Interface Design
- Subject: Re: Scripting Interface Design
- From: Christopher Nebel <email@hidden>
- Date: Fri, 22 Jun 2007 10:08:42 -0700
On Jun 21, 2007, at 7:29 AM, Philip Aker wrote:
On 2007-06-21, at 04:55:12, has wrote:
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:
http://www.latenightsw.com/blog/?p=32
Well worth a read. (I've already left my own 2c on the subject, of
course.;)
However, Scripting Interface Design now presumes an SDEF, so the
first questions should be about the SDEF schema because that now
defines everything.
I think you're confusing design with implementation, as was Mark to a
lesser degree. [1] Assuming I'm reading Mark's blog correctly, he's
mainly concerned with the Scripting User Interface (capitals because
it's an important concept), which is just the stuff the user sees --
the various terms and how they relate to each other. The actual
implementation could use an aete, or suite definitions, or an sdef.
[2] Yes, we want people to use an sdef, and there are various things
that are easier to express in an sdef, but the point is that for pure
design purposes, it doesn't matter.
That said, your suggestions have merit. Just to repeat...
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.
There are two major points here: one is beefing up the schema
(lowercase, since I'm not speaking specifically of XML-Schema; there
are other possibilities); two is the general role of mechanical
guideline enforcement.
For the first, it depends somewhat on what you think the role of the
schema is -- should it define *all* allowable behavior, or should you
delegate some of it to other external tools? Since the point here is
to make good design easier (and perhaps bad design harder), then some
sort of automatic enforcement would be useful. I'm fully in favor of
this -- I have several bugs to that effect -- but that enforcement
doesn't necessarily have to be in the schema itself. You could easily
imagine a tool, maybe a variant of sdp, that runs as part of the Xcode
build system and spits out warnings about things you're doing that
seem fishy. In fact, such a tool has to exist for complete coverage,
since there are some sdef constraints that XML-Schema can't express,
such as the requirement that codes and terms have a one-to-one
correspondence.
For the second, it's important to consider what mechanical enforcement
can do for you and what it can't. Some simple guidelines, such as the
NoInterCaps rule, are checkable, as are certain mistakes which will
cause your implementation to break, such as code/term mismatches.
This is good as far as it goes, but that sort of thing isn't what
makes scripting UI design hard. (Tedious, maybe, but not hard.) What
makes it hard -- and this was Mark's main point -- is making sure that
your scripting interface (that is, the object hierarchy and all the
commands) makes sense to a normal user of your application, and a
machine is never going to be able to check that for you. [3]
To sum up: more machine enforcement, great, but it can't solve any of
the hard design problems, so you still need human involvement.
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.
We should discuss this in more detail (though probably not here, it's
not germane to the list), but assuming I understand what you're asking
for, I regard this as something of a non-issue. First, as long as
it's conforming XML, you can add whatever you like, and none of the
other consumers in the system (the dictionary viewer, Cocoa Scripting,
sdp) will even notice -- none of them validate their input precisely
because we wanted people to be able to do that. Second, if you *do*
want to be able to validate your sdef (say, using "xmllint --valid"),
you can do that now by adding an internal DTD subset -- I've done this
myself for some projects. Now, it's true that certain types of
extensions are a pain, because the main DTD doesn't define any
particular hooks, so it would be nice to have something analogous to
what docbook [4] has. However, adding that rests on the assumption
that a significant number of developers actually wanted to extend
their sdefs, and so far, none of them are even using all the features
that already exist.
--Chris N.
[1] I was at those same WWDC sessions on the other side of the mic,
and I don't recall anyone asking anything that had to do with
scripting interface design, so I'm not sure where Mark got the idea
that developers find it difficult and error-prone. Implementing it,
sure, but not designing it.
[2] It's sdef, not SDEF, because it's a portmanteau, not an acronym.
Besides, I invented it, so I get to make the rules. =)
[3] Well, maybe not never, but not any time soon, seeing as how it's
an AI-complete problem. (See <http://catb.org/esr/jargon/html/A/AI-complete.html
>)
[4] Officially, <http://www.oasis-open.org/docbook/>, though <http://www.docbook.org/
> or <http://docbook.sourceforge.net/> may be better starting points.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden