Re: Collecting information from a client and sending it to the server

Saeed,
The model with SVG is that it can be used in any of the following scenarios:

1) Standalone/separately-stored drawings embedded by reference into a 
parent document (e.g., HTML with an <object> tag referencing "mydrawing.svg")

2) Drawings embedded inline inside of a parent XML document (e.g., XHTML 
with SVG inside using XML namespaces)

3) Standalone SVG documents - everything on the page is SVG

4) SVG content is the parent, with other XML languages (e.g., XForms, 
XHTLM) embedded inside of it

(Note: some of the above cases can be used together on the same web page, 
such as XHTML with embedded SVG which has embedded XForms)

The basic idea is that SVG sticks to its role as advanced-graphics-in-XML, 
and that when you need facilities that are already taken care of by some 
other W3C specification, then use that specification in combination with 
SVG, rather than extend SVG to have every possible feature that might exist 
in HTML, for example.

Over the long-term, this idea will be very powerful, especially with the 
W3C's goal of modularizing all of their various language standards. (XHTML 
modularization is pretty far along, and SMIL2 modularization is 
well-specified and approaching Candidate Recommendation. SVG modularization 
hopefully will be addressed right after SVG 1.0 goes to Recommendation.) 
For example, an implementer could add the XHTML Forms module or an 
implementation of XForms to an implementation of SVG. I would propose that 
one of the outcomes of the SVG modularization effort would be a set of 
implementation "profiles" targeted at common use web page scenarios, where 
one such "profile" specified all/most of SVG along with various modules 
from XHTML, such as Forms and text flows. By identifying a set of 
interesting "profiles", then implementers will tend to implement these 
predefined collections of modules, thereby promoting interoperability.

Jon Ferraiolo
SVG Editor
jferraio@adobe.com


At 11:27 AM 1/27/01 -0600, Saeed Akhter wrote:
>After looking over the specification, I have been unable to find any sort of
>form element as there exists in HTML.  Undoubtedly, any web-based
>application that will need to collect data from a user.  I am assuming that
>it was left out of the specification to keep it cleaner, but how exactly
>would approach this?  Would you embed html inside an SVG document or visa
>versa?  It seems to me that SVG is capable of providing a totally immerse
>environment that would be great for making a 'web based shopping
>application' with interactive items that could be dragged and dropped into
>your cart. (without the aid of HTML)  It seems like a feature that is
>relevant, after all I believe Flash has various kinds of form elements...
>
>Any thoughts?

Received on Thursday, 1 February 2001 11:54:41 UTC