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