OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] dynamically generated XML Schema?! Re: [xml-dev] R:[xml-de

[ Lists Home | Date Index | Thread Index ]


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?



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


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS