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.

[snip]

> 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
I'm 
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
make 
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
argument, but...).

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

2.  Do I demand that a stylesheet is always archived with the XML
instance?  

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
point 
and click creation and modification will be.  If DSSSL/Scheme is the
export/import/
archival and under-the-scene processing language, great.  Those are 
implementation issues, though, amenable to libraries.  It could be C and
production 
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.

len

Received on Tuesday, 4 March 1997 14:26:40 UTC