Minutes of XML Protocol WG telcon 2/21/2001
Roll call
PRESENT 41/33
Active Data Exchange Richard Martin principal
Allaire Glen Daniels principal
AT&T Mark Jones principal
AT&T Michah Lerner alternate
Bowstreet Alex Ceponkus alternate
Canon Jean-Jacques Moreau principal
Commerce One David Burdett principal
Compaq Kevin Perkins alternate
Compaq Yin-Leng Husband principal
DaimlerChrysler R. & Tech Mario Jeckle principal
Data Research Associates Mark Needleman principal
DataChannel Brian Eisenberg principal
Engenia Software Eric Jenkins alternate
Group 8760 Dick Brooks ebXML contact
Hewlett Packard David Ezell principal
IBM John Ibbotson principal
IBM David Fallside chair
IDOOX Jacek Kopecky principal
Intel Randy Hall principal
Interwoven Mark Hale principal
Library of Congress Ray Denenberg principal
Lotus Development Noah Mendelsohn principal
Matsushita Electric Ryuji Inoue principal
Microsoft Corporation Paul Cotton alternate
Microsoft Corporation Henrik Nielsen principal
Mitre Marwan Sabbouh principal
Mitre Paul Denning alternate
Netscape Ray Whitmer alternate
Netscape Vidur Apparao principal
Novell Scott Isaacson principal
OMG Henry Lowe principal
Oracle David Clay principal
Philips Research Amr Yassin alternate
Philips Research Yasser alSafadi principal
Rogue Wave Patrick Thompson alternate
SAP AG Volker Wiechers principal
Sun Microsystems Marc Hadley principal
Tibco Frank DeRose principal
W3C Hugo Haas alt team contact
W3C Yves Lafon team contact
WebMethods Randy Waldrop principal
AUTOMATICALLY EXCUSED
IDOOX Miroslav Simek alternate
Active Data Exchange Eric Fedok alternate
Allaire Simeon Simeonov alternate
Bowstreet James Tauber principal
Canon Herve Ruellan alternate
Commerce One Murray Maloney alternate
Engenia Software Jeffrey Kay principal
IBM Fransisco Cubera alternate
Interwoven Ron Daniel alternate
Library of Congress Rich Greenfield alternate
Oracle Jim Trezzo alternate
Rogue Wave Murali Janakiraman principal
Sun Microsystems Mark Baker alternate
REGRETS
DevelopMentor Martin Gudgin principal
Akamai Technologies Mark Nottingham principal
Calico Commerce Rekha Nagarajan principal
Cisco Krishna Sankar principal
DaimlerChrysler R. & Tech Andreas Riegg alternate
DevelopMentor Don Box alternate
Ericsson Research Canada Nilo Mitra principal
Hewlett Packard Stuart Williams alternate
Jamcracker David Orchard principal
SAP AG Gerd Hoelzing alternate
Software AG Michael Champion principal
Unisys Lynne Thompson principal
Unisys Nick Smilonich alternate
ABSENT WITHOUT EXPLANATION
Epicentric Dean Moses alternate
Epicentric Bjoern Heckel principal
Fujitsu Software Corporation Kazunori Iwasa principal
Fujitsu Software Corporation Masahiko Narita alternate
Informix Software Charles Campbell principal
Informix Software Soumitro Tagore alternate
IONA Technologies Oisin Hurley principal
IONA Technologies Eric Newcomer alternate
Progress Software Peter Lecuyer alternate
Software AG Dietmar Gaertner alternate
Vitria Technology Inc. Waqar Sadiq principal
Vitria Technology Inc. Richard Koo alternate
Xerox Tom Breuel primary
XMLSolutions Kevin Mitchell principal
XMLSolutions John Evdemon alternate
Review of the agenda
Approval of minutes from last week telcon
Minutes were approved
Action items
Comments on DS8 scenario - stricken - will be discussed today
805/807 to become part of requirements - done
Henrik - SOAP issue list to be included in XML Protocol issues document - done
Henrik - put pointer to SOAP issue list - done
David Clay - strengthen wording on early uniform normalization and
protocols
handling included data - done
Report on status of SOAP specification document
Response to Character model document
revised text posted -
Noah has suggested small changes - suggestion was made to either expand or
remove last sentence. - it was agreed to remove it
Paul asked how many comments were in reply - asked that the comments be
numbered -some identification of comments will be done - they will be
numbered ant title will be added
Question was raised as to whether the text "as necessary" was clear enough
-
there was some discussion of this - there had been some agreement to split
things on header/body axiom - Noah raised some concern about this in terms
of the fact that the header to one system might be the body to another -
would prefer to be more vague. Henrik agreed with this. Noah raised issue
of an xml file server which may not want to take responsibility for
normalizing data it has received. Issue was raised that this happened
because xml was used for the envelope - suggestion was made to not use the
word header. - Henrik raised issue of term as necessary since it could
argued it was always necessary - suggested revision was to change 2nd
sentence in 3rd paragraph to normalize parts of the message as appropriate
Noah suggested (with some assistance from others) - An xml protocol
processor may normalize those portions of the message on which it acts
directly, and will defer to applications any normalization that may be
required for processing payload(s) - question was raised as to why "may" was
used. Noah asked about an xml processor sending on the wire messages - was
this for outbound or inbound messages?
Noah - do we make a statement about what senders do? Currently response is
ambiguous about whether we are talking about senders or receivers. XM
processors are encourage but not required to normalize data for messages
they are sending - text above should apply to receivers of data.
Suggestion was made to separate payload from headers - Noah believes there
are no normalization required for the xml protocol header elements - at
least not currently in SOAP. Question came up whether this might apply for
extensions.
Question came up about whether we allow non normalized data in SOAP body?
David F believes this had been resolved in earlier discussion - David F
asked about how we should treat 2nd case where body of message is XML? -
are we responsible for that or not - Noah believes this was what the above
discussion was about
Noah suggested one possibility was to say nothing about senders and use text
above for receivers - other option was a symetrical view for both sender
and receiver.
David F mentioned we need to deal with agenda item 7 at some point - he is
inclined to continue with character model discussion since we need to have a
reply by end of week.
Discussion continued on character model document
Question was raised as to whether normalization in regards to XML Protocol
elements was a non issue or not sicne all elements defined were in US-ASCII
- what effect dis this have extentions - could we make a design decision at
this point to say that we will only define elements in US-ASCII - what about
status or error messages?
Suggestion was made to respond to I18N that based on current design and
where we are in designing protocol it might be that normalization would not
be a problem with protocol element. David F suggested we tell I18N that in
general we do not feel it is XML Protocol's responsibility to deal with payload - we
are in favor of normalization of protocol elements but we agree too early in
design to say anything more specific - Noah suggested we state we are still
in early design phase and that we have tentatively decided that we don't
think normalization of xp elements were needed but that we believed that
payload normalization was not something we believed was XML Protocol's responsibility
(or words to that effect) - also that we tentatively agreed to take
responsibility for normalization required for limited things like status
and error messages where required.
Noah proposed revised text as follows in place of current comment #3 :
Para #3: The XML Protocol Workgroup is still in the design process.
Tentatively, we propose to adopt the following design direction:
a) Our fixed vocabulary (e.g. ENVELOPE, HEADER, etc.) are expected to be
expressible in US-ASCII for which no normalization issue exists.
b) With respect to other control information generated or acted upon by the
XMLP Processor itself (e.g. text status messages), we expect to require
early normalization by senders, but no renormaliztion by receivers.
Receivers may reject unnormalized control information.
c) The XML Protocol Processor will defer to applications any normalization
that may be required for sending and/or receiving application payload(s).
Reason: Consider the example of an XML Protocol message containing a very
large >>XXX deleted the word text XXX << payload >> being sent for
storage in a filesystem: we do not believe either from a performance or
philosphical point of view that it should be the responsibility of the
transport or communiction layer (XML Protocol) to manipulate the payload in
such a circumstance. <<
Proposal was made to accept Noah's suggested text above as response to
I18N
- It was suggested that this comment be moved to the top of the comments -
David F suggested that this might be all the comments we needed to send in
-
Noah believed current comment #4 could stay in which referred to optional
attribute about normalization.
David F proposed Noah send his text to private list and David weave it in to
existing text and post it back to WG - and WG sign of on it - David F asked
whether there was any strong objection to this as a response modulo the fact
that they havent seen the actual text. Deadline will be 2/22 noon pacific
time for comments or objections. - small editorial changes can be made
modulo David's time by noon tomorrow pacific - the language Noah used
specifying US-ASCII will be corrected to reflect what ever the proper
language should be - David asked that cut off be changed to 3pm pacific
tomorrow - agreed