[
Lists Home |
Date Index |
Thread Index
]
Jeff,
Thanks for this example. I got to something similar.
But there is one thing troubling me: 1) Either one assumes a generic
software that generates the complete form from any XML Schema. The forms
will not be layouted very well (or the schema has some annotations to
allow layout), and it seems inefficient to me to do this dynamically
(i.e. every time the use makes her printRequest). You only need to
specialize the schema once (e,g, when you configure the printing
application), and all print requests use the same.
but ok, assume (2) we have a cool operating system/servlet
engine/library that provides this "form from schema" service. The
application writer that wants to get these forms can assemble a
complete, specialized schema only at runtime.
Then, indeed, one could not have used *any* format X, because we want to
validate the form fields. This is what I call a good example!
Specialization (rather than extension) and the need for validation seems
to be a part of the "dynamically generated XML Schema" story.
Another thing which I take from this is that it does not really matter
how the XML Schema is (it's enough to know the representation that the
"form from schema" service uses, be it DOM, XOM, or whatever).
If there was something like "parameterized schemas" (like Java
generics), to which extend would this make specialization easier?
Wouldn't it be good for this sort of application to have a
"parameterized schema" (thus a partial schema), and complete by plugging
in the missing bits?
cheers,
Burak
http://lamp.epfl.ch/~buraq
Jeff Greif wrote:
>>>Why generate schemas dynamically? What's the advantage of an XML
>>>Schema language for this?
>>>
>>>
>
>Consider an application that consumes schemas, say, to generate forms for
>user input. (Based on a type in a schema, it generates a form.). Sometimes
>the type can be specialized to make things easier for the human entering the
>data, or for validation of the result.
>
>For example, in a large institution like the headquarters of Microsoft, you
>might have forms on the Intranet to produce documents like this for
>centralized services:
>
><printRequest id=:"234567">
> <printerLocation>Marketing 3rd floor east</printerLocation>
> <printerType>color laser 2400dpi</printerType>
> <paperType>glossy press release</paperType>
> <paperSize>letter</paperSize>
> <document>"\\WinAlways\c:\Results\Profits UP Again.xls"</document>
> <user>Joe Hypester</user>
></printRequest>
>
>If the schema were static, printerLocation would likely be defined to be
>some kind of string. However, when the form is generated for the user, a
>list of available, in-service printer locations could be retrieved from the
>database, and, instead of having the user type in one, she could select from
>the list. The list could even be sorted to put printers known to be nearest
>to the user's office near the top of the list. In this case, generating a
>schema on the fly for the PrinterLocationType as an enumeration and passing
>that to the form generator would be one way to improve the presentation and
>validation. The schema cannot be static because it is the way of printers
>to be out-of-service occasionally, and new ones to be added to the list
>occasionally. The template for the dynamic schema and the list of printer
>locations could be merged using an XSLT in an XML-based schema language, but
>this is a relatively minor benefit..
>
>Jeff
>
>
>
|
