Re: Scripting Interface Design
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