Re: Addressing....

At 11:02 AM 1/8/97 -0500, you wrote:
Gavin Nicol wrote:
>> I do not object to fragment specifiers, but this argument is
>> specious. You could just as easily say that a client could recognise
>> that it could retrieve the entire entity, and then walk it's own parse
>> tree based on the URL's I propose.
>
>I don't think the client is allowed to play around with the section of the
>URL preceding the "#" that much.
>
...

JavaScript has an "onSubmit" event-attribute that can be used within a Form
to "intercept" the contents of text-fields before they are sent to the
server as a query string. The script can perform local processing on the
data and then (optionally) allow the original data or some result of the
processing to be sent on to the server for further action. One of the main
current uses for this capability is to validate the contents of the form
before sending it to the server, but there are many other possibilities.  

Obvious issues are that "onSubmit" only works inside a Form and depends on
JavaScript, and neither of these is a part of XML. If Microsoft and Netscape
pick up on XML however, I would expect them to extend the code they have
now, not write "XML browsers" from scratch. That means supporting existing
HTML semantics, including Forms, as well as the scripting and Java language
support they've been adding to their browsers. Said another way, I believe
XML will also have to address support for scripting languages and "common"
HTML semantics (like Forms). Possibly the SMSL work in ISO will produce
something that can be adopted. In terms of the discussion here, I believe
it's at least useful to be aware that using a fragment specifier is not the
only way that client-side processing can be invoked. 

Regards,

Ralph E. Ferris
Project Manager, Electronic Publications
Fujitsu Software Corporation

Received on Wednesday, 8 January 1997 14:18:20 UTC