OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: attribute order (RE: Syntax Sugar and XML information models)

From: Simon St.Laurent <simonstl@simonstl.com>

>Remember that we don't all have access to the archives, and I can imagine a
>number of reasons for arguing either way.  (It's pretty easy to argue about
>how useful the various distinctions between elements and attributes really
>are in general - this is just one case.)

I think to have this discussion would require access to ISO minutes from the
mid 1980s.

When ADA was being developed they decided that the feature of command-line
interfaces (e.g. UNIX commands) where you provided named arguments rather
than relying on positions was pretty useful: not only did it make the
program more self documenting, it provided a clean alternative to varargs
and reduced error rates. (There is an interesting article at Rational's
site, based on a large SW development on which there had been lots of
measurements taken, that ADA was about twice as easy to maintain as C.  ADA
probably gets a too hard time, on those facts at least. There are a lot of
assertions, and programmers have voted with their feet (or with their
preference for UNIX and curly braces), but one shouldn't dismiss measured
results out of hand.)

So SGML seems to have adopted named arguments, like command-line interfaces
and ADA and Common LISP, as part of best-practise sofware engineering as
seen in the early 1980s.  SGML also allowed anonymous attributes ( e.g.
<size  large>)  but did that by enforcing a unique token rule on attribute
values rather than positional dependence.  DSSSL reintroduced keyword
arguments into Scheme, but the mix of some named, some positional means that
"positional" becomes "relative order of anonymous arguments" rather than
"absolute order" which has always seemed a little messy to me (I think many
people would agree that command line interfaces which use relative order for
more than two meanings are rather difficult)

So those are some design axes: named/anonymous, fixed/free position, where
anonymous+free implies that the value tells you the effective name.

Of course, the advent of IDEs and strongly typed languages means that the
IDE performs implicit labelling and has reduced the need for explicit
labels, but this is
only reliable when the arguments have different types discernable from the
I wonder if the use of pre-conditions (asserts) as espoused in Meyer's
by contract" is too some extent prudence in the face of anonymous function
arguments: if you have named arguments you can use a built-in
type-declaration system, but if you have anonymous arguments whose type
differences cannot be resolved lexically then you need an ad-hoc type like
precondition-checks.   (Of course, Meyers has other reasons for programming
by contract, and certainly not all "argument-in-the-wrong-position" can be
detected either by lexical space or value space checks...only the ones that
are square pegs in round holes...which in turn tends to support SGML's
unique enumeration value rule for attributes, however inconvenient it is.)

Rick Jelliffe