Query Languages for XML

[Derek Denny-Brown]

At 11:50 AM 11/21/97 -0500, Paul Prescod wrote:
>Derek Denny-Brown wrote:
>> 
>> One of the things that I see as a potential problem is that HTML etc as it
>> is used now has 2 (as I count them this side of the morning) relatively
>> distinct uses.
>>         1) as an alternate form of (relatively) static information.
>>         2) as a (very-basic) cross-platform (g)ui.
>> 
>> XSL and DSSSL are focusing rather hard on (1), but not on (2).  
>
>I'm not sure what you mean by that. XSL as currently proposed has access
>to all of the form features of HTML, just as it has access to all of the
>static display features of HTML. It is correct to argue that we are
>spending more effort on *improving* HTML's static display features than
>improving its form features, but I think that that is probably
>appropriate considering the market's interest in better static pages,
>SGML's particular strengths in that area and Java's suitability for
>forms.

I have a difficult time understanding how a "call-back" would work in XSL,
since the processing model does not include any mechanism for such
callbacks. This sense given that XSL is (at least to this point) about
transforming XML to a displayable view.  The problem is when that display
able view is interactive.  I am not talking about FORMs, where the
interaction is between the browser and the server, but rather interaction
between the user and the browser, a-la JScript/JavaScript, onMouseOver,
etc... What if I have two (or more) possible way to view (ie. differing
applications of a styelsheet) some content.  I am not looking to reprocess
teh whole, pag,e but rather to reprocess just a small portion and swap out
a portion of the existing/original flow-objects for the newly generated
flow-objects.  Or, as a simpler case, to just modify the attributes of
existing flow objects.  Using HTML forms as a example, it would be really
nice if you could performs some sanity checks on the contents of the form
before it was sent to the server.  One of the problems with most currnet
scheme's which do this is that they provide no clear indication of what
they think is wrong, when the sanity checking is done.  It would be better
if they could use color or some such thing to indicate which fields have
data which it considers invalid.

The way all this (and most of JavaScript) is done now is through
call-backs.  You register a function as a call-back in the case a specific
event happens (such as the user pushing the submit button, or the user's
mouse moving over a specific image).  I am unclear how XSL could handle
such a call-back.  For what I would want, it really needs a queriable model
of the flow-objects which were created originally, and some way to modify
those flow-objects.  Now your XSL style sheet has two portions, one which
takes the XML document and builds a complete flow-object stream/tree.  The
other handles callbacks from user-generated events regarding flow-objects,
and modifies the flow-objects.  This second part is what "dynamic" HTML is
all about. (Either through Netscape's JavaScript or Microsoft's dHTML,
though dHTML is more like what I am talking about.)

If you have looked at some of Microsoft's MSXML samples which use DSO (I
think that is what they call it...), that is kind of in line with what I am
talking about, though in that case the original flow-objects where directly
HTML, not generated from XML...

-derek

     Derek E. Denny-Brown II      ||   ddb at criinc.com
     "Reality is that which,      ||   Seattle, WA USA
  when you stop believing in it,  ||  WWW/SGML/HyTime/XML
 doesn't go away."  -- P. K. Dick || Java/Perl/Scheme/C/C++

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)