Re: 3.1 b-h: BEHAVIOR
Again: rule of ricebowl: owner of solution defends the problem.
In this case, me, not Chris.
>Christopher R. Maden wrote:
> I have a real problem with this level of behavioral specification. I
> understand Len's desire for behavioral buckets, but I think there's a
> better way to do that.
> Asserting links and establishing relationships, yes. Specifying
> behavior, no.
I can fall on either side of this, but let me play devil's
advocate because I've seen this done different ways in SGML systems.
Stylesheets and behavior have nattered at us for a decade, so
if we think we can solve this now, I guess phase III will be
as noisy as Phase II. Ah so...
First, the behavior attributes chosen for XML are confusing to me, so
just following the debate. I am probably influenced by the simpler
notion of the MID that a behavior attribute is there to
declare what to do with state and so, gosub/goto/spawn/other
are sufficient. (I don't like "other": it is the black hole.)
It is only useful if a link is specifying active traversal;
not a passive relationship.
It is necessary to understand that MID IS an application:
a GUI scripting language over a database of anything, or in my words,
a database sequencer. It's conceptual parent isn't HTML;
it is Visual Basic and the Zinc and XVT portability toolkits.
For what it was designed to do, it
works because like HTML, the author has an easier time with
scripts that correlate directly to screen objects. The trick was to
those as metaAsSensible, then get on with it. It is not
a generic solution for the database information: it
is reasonably generic for the navigation interface and
declaring navigation of stateful relationships.
Does XML need this, or is XML better seen as the language
of the database an application like MID navigates?
Should one consider rewriting MID-like apps as XML applications,
or can they?
There are other ways. There are sometimes better ways.
Then there are THE ways this is expressed. Since no XML
clients exist (publicly) but there are SGML browsers and
HTML browsers that do use attributes to specify that a
behavior is *expected* on a link:
o name a bucket for it. make its use optional and warn
that this attribute spawns subdomains XML doesn't constrain.
o name the behaviors and be precise about what they do.
o say that XML can be used to write languages
with active objects if the behavior is added by a
separate application architecture (eg. like MID uses
a MID arch form and a HyTime ilink).
Otherwise, what is to be done with action= tags that
have already shown up in two SGML DTDs for web use?
The Dynatext way is a way but to me, this is "The SGML Way"
in a world in which too many users already do it other ways
and some do it with SGML. If XML restricts that, it only narrows
its own field of application. (Strange to be on this side of that
There will be times when the stylesheet and the
instance go down separate paths to separate destinations.
1. Should the user be restricted to fixed methods, or laissez
faire, or is the behavior attribute just a flag for
the middle way? IOW, here is what is expected, but
2. Do I demand that a stylesheet is always archived with the XML
3. What is easiest for the author (not a stylesheet designer) to use?
I don't expect native DSSSL scripting to be a raging success. I expect
and click creation and modification will be. If DSSSL/Scheme is the
archival and under-the-scene processing language, great. Those are
implementation issues, though, amenable to libraries. It could be C and
user shouldn't know the difference. It is the buyer of the system who
needs to know if standardized stylesheet export and import is required.