• 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: Philip Aker <email@hidden>
  • Date: Sat, 23 Jun 2007 03:13:36 -0700

On 2007-06-22, at 10:08:42, Christopher Nebel 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.


Hi Chris,

I think you're confusing design with implementation,

No, not at all.


as was Mark to a lesser degree. [1]

The article's topic immediately perceptible and clear to me. My remarks address cause. I admit it's requires detailed knowledge to see the relationship though. So very glad you made it through.



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.

That was part of my impression. However I feel that the statement: "It’s about designing a programatic interface for an application that mirrors the user’s view of the application’s data model and functionality.", enunciates his quandary more specifically. Here the topic is instantly multi-disciplinary, multi-cultural, and very complex for goods that people can touch. Even more so for software interfaces. Psychology, and industrial design come to mind. To give a hardware example, the iPod, where the classic "less is more" approach has given Apple a success story, has a huge amount of thought and re- working put into its design.


We have to go a step further and abstract things into a Scripting Interface…


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.

Yes, I understand that fully. But sdef is the big daddy now so it's the obvious vehicle to convey my comments. Tweaking the aete resource definition at this stage seems an unlikely possibility.



That said, your suggestions have merit.

Thanks very much. I'm truly concerned about a few aspects since I have gone quite a few steps into a CoreFoundation parser and spent some time on an XML schema for them.



Just to repeat...

1.

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.

2.

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.

3.

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

I think the role of an sdef schema is to define the language unambiguously (paragraph 1 : last sentence, paragraph 3 : first sentence) and do so at the international standard level of our time. From that follows many things, including what Hamish Sanderson picked up on immediately, IDL.



-- 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.

Well, maybe you can't speak about the alternates right now, but I'd just like to say that XML Schema is the international standard for good reason. And one of my principal concerns is that Apple won't get duped into using something like Relax-NG or Schematron. Not because they're not good, but because XML-Schema is more appropriate for a language definition. It's also the harder, but not unattainable possibility with a tweaked sdef. I'm prepared to elaborate at length on the merits of XML Schema for this purpose.



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.

Easily is correct. I have a non-validating tool, sdmerge, which does something sdp can't do right now used in an Xcode build phase. I decided to forego any validation because I figured you'd be upgrading both sdp and the schema anyway.



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.

Perhaps you can elaborate? I think what you want is an attribute group (use="required") but maybe you're talking about something else.



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]

See "However I feel that the statement:" above. :-). I really do get his point. I've considered things like this in depth (prompted by copious and meaningful comments from day job QA folks).



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),

I will copy this reply to scrimps and continue it there. But I'd certainly like to invite folks over there and participate if so inclined.



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.

Ok that's real good to know.


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.

I don't know the docbook specifics but what I mean is a formally defined extension element for the schema that would be _passed back_ to the application for implementation (via appinfo). One that doesn't require a Cocoa API (but could if that was your only language choice). Schematron for instance works via appinfo. This is much better than having to use <?processing-instruction xxx?>. You might be able to test with a <comparison-operator … > element that while defined as an extension, would magically make it back into an aete because the appinfo would indicate something like: <implementation … aete-compat="yes" … />




Philip Aker
email@hidden


_______________________________________________ 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
References: 
 >Scripting Interface Design (From: Philip Aker <email@hidden>)
 >Re: Scripting Interface Design (From: Christopher Nebel <email@hidden>)

  • Prev by Date: Re: help scripting apple mail
  • Next by Date: Re: help scripting apple mail
  • Previous by thread: Re: Scripting Interface Design
  • Next by thread: Re: Scripting Interface Design
  • Index(es):
    • Date
    • Thread