• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Scripting Interface Design
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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
  • Follow-Ups:
    • Re: Scripting Interface Design
      • From: Philip Aker <email@hidden>
References: 
 >Scripting Interface Design (From: Philip Aker <email@hidden>)

  • Prev by Date: Re: AppleScript for adding JavaScript to a page which is getting loaded
  • Next by Date: Re: Scripting Interface Design
  • Previous by thread: Scripting Interface Design
  • Next by thread: Re: Scripting Interface Design
  • Index(es):
    • Date
    • Thread