Re: 3.1 b-h: BEHAVIOR

Christopher R. Maden wrote:
> 
> [Len Bullard]
> > Does XML need this, or is XML better seen as the language of the
> > database an application like MID navigates?
> 
> I prefer to think of XML as the language for the database itself.  XML
> is a markup language - that which is being marked up is data.  An
> application could certainly use XML to mark up its specifications, but
> just because the same language can be used does not mean information
> should be stored in the same place.

Ok, and understood.  I consider that position a religious one.

Markup of data vs markup of text that an interpreter treats 
as instructions are still just markup.  XML should neither prefer 
not prevent either.  Too many designers find it useful or 
convenient to markup processes (e.g, action=) and include 
behavioral specifications for it to be disregarded by the 
WG for purely religious orientations.  Separate church and *state*.

> The data - textual content, metadata, and relationships between
> infoquanta - should be contained in the XML document.  

Yes.  But relationships are either passive records or active 
structures.  They have a clickable interface or they don't.
If the stylesheet is used to tell the system that an <a is 
a hotspot, why bother with XML Link at all?  When does the 
division bell ring on that debate?  As soon as the context 
link is added, process is added to a document. 

> Suggested (or required) behavior should be stored separately.  

If there were a technical reason for that other than someone 
might prefer curly brackets over pointy brackets, it might 
be a good point.  But when I open an HTML file and see function 
calls in attributes values, a script tag full of curly brackets, 
etc., I think this religion is out of style, out of date, 
and out of time.  XML should be agnostic about that.

> I should be able to
> open the document in SoftQuad XenoMetaL Style Editor and turn off the
> d*mn flashing bullets in front of every item in the Luddite Manifesto.

Yes, well, depending on where you fall on the "author intention vs 
reader privilege" debates.

> If the transclusion of those bullets is hardcoded in the XML source, I
> can't do that - unless I can override the suggested behavior in the
> stylesheet, and if that's true, why not just use the stylesheet
> always, since browsing will be sort of useless without it?

Because there are times when to repurpose data, or simply to make it 
smaller, no stylesheet will exist.  Any tightly focused app such 
as CML, MID, etc. may not offer many style options, and even these,  
as with IADS, may be in a proprietary stylesheet format with a 
point and click interface because the application designer or the
requirements 
specify that only the document is portable, archivable, etc.
For these cases, as in HTML, it is convenient to indicate the 
behavior for active links.  A static relationship link is 
only a record of a relationship.  An active link (e.g, a 
hypertext link as common practice sees it) is a record and a 
control interface (clickable).  This is probably the piece 
that keeps bothering everyone.  While this can be achieved 
by indirection, it isn't the only way and in many cases, 
by empirical observation of existing systems, not always 
the best way.  Again, XML should be agnostic about that.

> And yes, I don't expect many people to be editing DSSSL directly; I
> think there will be shared stylesheets for common DTDs, which people
> can tweak bits of by hand, and editors for creation of new ones.  Most
> users of XML will either be able to deal with DSSSL or will be using
> simple DTDs they pulled off the 'net.

Some.  Some will design ground up.  Some will take bits and pieces 
and adapt them.  I suspect a good number of DSSSL rendering 
processing specs will just be Jon's HTML version with different 
GIs and some additional attribute handlers.  The main problem 
we will have selling the approach will be to convince someone 
that they can handle a laissez faire hypertext medium.  We faced 
this with IADS and IDE/AS.  If a user wants style freedom, they 
get style responsibility.  If a designer wants to have behavior 
flagged in the markup, they get to implement the handlers for 
those *proprietary* tags.  

How one views the behavior attribute is exactly the same as how 
one views all of the other *application* features of XML Link.  
XML Link is an application of XML Markup.  It is an application 
we are all agreeing on now to provide interoperability for XML 
applications of hypertext.

Heck:  Tornado warning.  Time to sign off and hide in the 
middle of the building again.  Later... 

len

Received on Wednesday, 5 March 1997 15:00:02 UTC