Re: Interactive XML

At 10:47 AM 6/27/98 +0100, Martin Bryan wrote:
>Sharon
>
>
>>Martin, we do not know what will be included in version 1.0 so you
>certainly
>>do not.  Please do not make statements that imply you have information that
>>you do not have.  Version 1.0 of XSL is scheduled for July, 1999.  We are
>>working feverishly to get out a small Working Draft for next month.  It
>will
>>not provide you with information on what will be in the July '99 document
>>either. It is our FIRST WORKING DRAFT and we should be given the courtesy
>to
>>have some time to develop coherent, well thought out, workable proposals
>for
>>this complex subject in more than 4 months.
>
>I am sorry if my message upset you. However, I  would point you to my actual
>words, which you do not seem to have read: "I live in hope and eagerly await
>next month's *draft* in the hope I will be proved wrong."

Martin, I very much READ your comments and that is why I wrote.  You said
and I quote
"I live in hope and eagerly await
>next month's *draft* in the hope I will be proved wrong."  This appears to
the naive reader that when there is no interactivity in the July Draft that
we aren't doing it.  That is not so and I wanted to make certain that people
could understand that.   I've known you for years and if you have questions,
instead of jumping to conclusions I would appreciate the courtesy of asking
for information directly.  If I am able to answer I will. We could spend our
time writing requirements documents or spend our time writing Standards.
Which do you prefer?  Beautiful requirements documents but no time to do
Standards to back them up.
>
>I was under the mistaken impression from what had been said previously
>that the final text had to be sorted out in Sept/Oct for voting
>on by January. Such a schedule would not give us time for debate about
>requirements, which was one of my concern areas. I have previously noted
>that there were no adequate statement of requirements re interactivity
>prepared for the first draft, which seems to me to mean that there cannot be
>any such features until version 2.0, which will be at least a year after the
>1999 date of Version 1.0. The revised timetable will make it easier to lobby
>for what is required to be put in Version 1.0, but not having seen any
>revision of the user requirements, or the first draft, it is very difficult
>for me to come to any clear determination.
>
>I would remind you that there is much other work held up waiting for the
>decisions of your committee. In particular I am unable to determine how much
>work is needed for interactivity control within the XML/EDI projects that
>are currently being proposed worldwide because of lack of guidance as to
>what the aims of the XSL committee are in this area.
 
News to me.  If you need information I would suggest that you use the formal
channels to get the information instead of making it up on your own.  We are
not mind-readers.  The requirements document was designed to give a flavor
of the areas we tend to pursue.  If you have specific information you wish
to know please let us know.  I answered one set of your questions already.
I would gladly do so again.

When we work on interactivity we will consider the requirements you have
listed herein.  

Once I know what you
>plan to do I can do something about explaining to an industry that is now
>keen to start actively exploring the role of XML what they can do with it.
>
>The XML/EDI community has a much wider need for interactivity than those
>currently being discussed by this list. Simply providing the functionality
>found in HTML
>forms or exsiting GUIs is *not* sufficient for this potentially very large
>user community.
>For electronic commerce you need to be able to extend the simple form
>creation specification currently being considered to do things like:
>
>a) check that the value entered in a form conforms to a predefined lexical
>value,
>or matches one of the entries in a referenced database (either on the local
>server, in cached memory or on a remote server)
>b) create menus whose lists of options can be created on-the-fly by
>selecting options from
>a referenced database
>c) allow the selection of one item in one menu to change the contents of
>another menu (e.g. if I select Supplier  X then the list of options in the
>next menu changes to display only those items created by Supplier X) without
>having to make an additional call over the clogged network.
>d) allow sections of forms to be removed from, or added to, the display when
>a certain option is selected for a particular field.
>
>Most of these functions could be acheivable with a few extensions to
>ECMAScript,
>provided that this general purpose langaguage is adopted by XSL as the main
>means
>of associating programmable behaviour with XML elements. At present it is
>far from
>clear that this will be the case.
>
>My one big worry is that I will have to tell the XML/EDI user community
> "Sorry XSL cannot do what we need it to do, so we will have to develop our
>own interactivity control
>language, and drop the idea of using any features that may later on be
>standardized as part of XSL". At the moment this, unfortunately, looks to me
>to be
>the most likely scenario in the XML/EDI world.

Perhaps, but that will only happen if you want it to happen.  This committee
deserves more than 4 months to write a complex standard that must do more
than just what you wish it to do.
>
>Martin Bryan
>
>
>
> XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
>
>


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list