• 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 05:27:22 -0700

On 2007-06-22, at 10:41:04, has wrote:

However, Scripting Interface Design now presumes an SDEF, so the first questions should be about the SDEF schema because that now defines everything.

For benefit of those who don't know their DTDs from their schemas (e.g. me), could you be a bit more specific,

Oh man, I picked up a book from the library a few years ago, and left it feeling like I still hadn't graduated kindergarden. Much later, I finally decided to bite the bullet and took out every book I could find on the topic including some compendiums which included chapters on schemas. That took two weeks straight. It's really about finding an author you can connect with. Unfortunately for me it's Eric T. Ray, and his XML book predates any Schema Recommendation. I can remember "The XML schema complete reference: Binstock, Cliff et. al." and I think there was one by some guys in a Wrox book that was good for me too.



with practical examples, about where the DTD format falls short or where the schema format could enhance the decriptiveness or reliability of sdefs?

Well, the DTD as it stands can't be validated by one checker I have. But that's not a big issue because it's a technicality and Chris has probably already fixed it. A huge issue is the 'type' as attribute or element duplicity that DTD lets one get away with but is illegal in normative XML Schema. It's not a small debate in the XML circles either because you can do it in Relax-NG and I think Schematron as well. In fact, that's why I decided to have a go at the schema books the second time because I'd heard about the issue and wondered if there was indeed a more compact expression.


However, I believe the reason this dualism is not in the standard is because it can't survive recursion and spit out itself. While this ability is not necessary for all definitions, I believe it spells suicide for a language description. When this vital flaw starts to manifest again with similar symptoms to those Mark now states in his blog, the engineer who took the unfortunate tactic of defining AppleScript in this fashion will be let go from his current position and live out his days out in perpetual chagrin.


I think what you're arguing for is turning the current sdef format into a full-blown Interface Definition Language which would allow developers to describe how an application's scripting interface works down to the very last detail.

Certainly implying the possibility.


I'm all in favour of that, of course, but it'll make more sense to talk about what kinds of information need to be expressible in an sdef before disappearing into an arcane discussion of what meta- format (DTD or Schema) will need to be used to describe the definition of the definition.

There's no doubt about that -- it's a schema. I think the sdef as it stands now needs a few tweaks to be eligible. But really, I think it's only a few tweaks, not a major overhaul. Consider that the basic design has emerged from aete.r -> .scriptSuite/.scriptTerminology. Obviously there's something in its abstract notion that indicates "survivor". We can use annotation elements and an XSLT transformation (or two) to do the rest.



For example, one comment you made which I did pick up is the desire for the sdef format to be extensible by third-parties. I can certainly think of one area where third-party extensibility would be valuable and fully justified: to support data-driven event handling frameworks. At the moment, the sdef format is limited to supporting only one event handling framework - Cocoa Scripting - however, a third-party framework such as aemreceive could also benefit from a data-driven approach. At the moment, anyone using aemreceive has to write additional code to install their event handlers, but if I they were allowed to put a few <implementation:aemreceive ...> tags into their sdef then aemreceive could install those handlers for them.

You've hit the nail on the head again Hamish. And indeed I've previously made a request for a 'carbon' implementation element. But you're on a better track by suggesting "implementation". We can immediately see that the presumption here is the hard-wired 'cocoa' element rather an uber implementation element with a namespace (i.e. default = cocoa) or as my first thought: <implementation type="xxx" … />.



Another good demonstration of where the sdef format currently falls well short of being an IDL is in the way that commands are declared. Let's take TextEdit's 'make' command as an example:

make
new type class : The class of the new object.
[at location reference] : The location at which to insert the object.
[with data anything] : The initial data for the object.
[with properties record] : The initial values for properties of the object.
→ reference

At the moment, there's _no_ way for either a machine or a person to tell from this definition what all the legal uses for the make command are [1]. How do I know which classes of objects can be created using make? For each of those classes, how do I know which parameters are required, which are optional, and which should be ignored? For each of those parameters, how do I know what sorts of values are needed?

Actually, the way I see it, quite a bit of this stuff is in the sdef. What you're talking about here is the _description_ (as it should be coordinated with the element attributes and sub-elements) not the _definition_. So that's just a transformation to user documentation, not a radical change in the sdef.



A proper IDL would allow developers to express all this information to users in a consistent, machine-readable way. For example, an IDL would tell you:

- To make a new document object, you must supply a 'document' constant for the 'new' parameter, that the 'at' parameter is optional but if you supply it it must be an insertion reference pointing to the 'document' elements of the 'application' object, that the 'with data' parameter should not be used, and that the 'with properties' parameter is optional (it could even describe what the structure of the record should look like, although I suspect that might be overkill).

- To add a paragraph to a document, you must supply a 'paragraph' constant for 'new' (required), an insertion reference to a document's character/word/paragraph elements (required), a string for 'with data' (required), and an optional 'with properties' parameter.

And so on, and so on. Every legal permutation of 'make' command usage would be documented, and likewise for every other command. That might sound like it's creating a lot of additional work for the developer,

Right now, I see the above as being a tweak (at most) to what's currently available. Check out the responds-to element.



I could go on, but I imagine most folks here will be falling asleep aready so I won't. However, the basic upshot is this: making the sdef format both comprehensive in detail and reliably robust will make it clear to developers what information they must provide so that users can understand how to use their application effectively. While writing a more detailed sdef does mean a bit more work for developers, I think they would much rather have that than no clear sense of what they need to do or unhappy users because they failed to do it correctly. And, most importantly, it would mean happier users, since learning to script each new application would no longer be a case of "Guess What All the Magic Invocations Are" as it currently is.

That's definitely a part of it. There are other less tangible design considerations though and I've touched on them briefly in my reply to Chris.



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: 
 >Re: Scripting Interface Design (From: has <email@hidden>)

  • Prev by Date: Re: help scripting apple mail
  • Next by Date: Re: OSAX to Tokenize Record Field Names from List Items ???
  • Previous by thread: Re: Scripting Interface Design
  • Next by thread: Re: Scripting Interface Design
  • Index(es):
    • Date
    • Thread