W3C XML Protocol Working Group teleconference, 19 December 2001

Minutes of XMLP Working Group teleconference, 19 December 2001.

1. Roll call

Present 26/24 Excused Regrets Absent

2. Review of Agenda:

As circulated, reviewed.

Three additional items of business:
(i) Congratulations on publication of WD.  Thanks to editors getting
documents ready and WG.
(ii) Note email to xmlp-member list asking for suggestions on plenary
meeting -- 1st draft of agenda is available, Pleanry organiser's are
soliciting additional items.
(iii) Now that WDs are published, a number of issues pending on the TBTF --
they will be reconvened in January. At F2F we agreed to scenario 2, which
implies we need to have complete set of documents at end of January (hint
to WG members: read WD documents over holidays!).

Schedule for media type draft.  -- covered in action items.

3. Approval of December 12th minutes.

Some mention of publications in these minutes, but since WDs have now been
published, it seems OK.

No objections were raised and the minutes were approved as posted.

Note on F2F Minutes which are not complete yet: The roll call and basic
administrivia are edited but it still needs to be edited so it is
understandable in 6 months to some outsider. This requires many hours of
work, which is not yet complete.

4. Review of action items:

* Paul Cotton drafting email to TAG on mime type.  Taken over by Mark
Baker. Status is still in progress.
* Paul Cotton to provide examples?  Changed to Henrik.
* Hugo send out message to Winston regarding Oct 31 minutes.  Done.  No
reply. Marked done.  To be taken up with rep off-line by Chair.
* Editors to figure out global plan. Done.
*  Issues list maintainers to close closed issues, including recent Ed List
sent to xmlp-comments. Done
* ChrisF. Pending/postponed until January.
* Jack resolution text issue 197. Pending. Done by next telecon in 3 wks.
* Glen Daniels, email to public lists.  Done.
* Mark Baker issue 138.  Still working, a lot of text to be written.  2/3
done.
Perhaps core is complete enough for submission.  Perhaps done by end of
week.
Media type work done by 3 wks.  Ask Mark Nottingham.  Mark Baker submitted
schedule
to put out by last call.  SOAP action header description 427 response and
another.
Submitted to IONA at a later date.  IONA's schedule perhaps 3 or 4 months
if all
goes well.  Some pushback expected from IETF surrounding security
implications.
We will discuss this as a group.  We should get feedback sooner.  Usual
suspects
who make the decisions are likely to give an indication up front of
expected schedule.
* Henrik start email thread on issue 127. Pending.
* Paul Denning hunt down issue 9. Pending. Expected for next telcon in 3
wks.
Chair reminds WG members that "in time for next telcon" means by end of day
monday of the telcon week.
* email dist app for information.  Info missing for groups 2 and 3.
Pending.
* Hugo follow up with QA.  No rely from.  Pending.
* Henrik and DF.  Pending/postponed until January.
* David Orchard draft reply to XML encoding. Done.
* Close 138. Done.
* Henrik ping PaulC and MarkB. Done.
* GMurali to enerate new text. Done.
* Stuart to ping glen to get feedback from soapbuilders. Done.
* Mark Hadley to write schema fragment for fault codes. Done.
* Noah during write-up of 101 to see if other issues generated.  Done.

5. Status reports:

Primer -- nothing.

Spec -- editors advise people to refresh the WD docs because of a bug that
lasted for about 15 minutes after announcements.

Paul Cotton: suggest WD Announce message should also go out to chairs list.

TBTF -- nothing to report.

ETF -- met this morning briefly, still going through issues, a number of
resolutions lined up but nothing to report.

Conformance -- nothing.

Usage scenarios -- nothing.

Our response to XML Encryption -- David Orchard not present so postpone.

Schema type library update -- XML Schema met F2F and had agenda item
regarding the XML Schema type library proposal in which XML Schema owned
the container of the type library but was not responsible for mediating the
types within the container/type-library.  XMLP's interest is to put
definitions such as array into that container. XML Schema WG did not get to
the agenda item and it is expected they will discuss it on Thursday.

Paul Cotton: I have not see any discussion about this on the (type-library)
list by people submitting types to the list.
DF: It was discussed on a telecon that took place before the list existed.
Schema did consider this before and rejected it, but Michael needs to
continue discussion.  Not discussed on list.
Paul: People on list from other groups should be engaged.
DF:  I will generate the email to the list.  Paul should supply list
address.

6. Issue 171. Murali expanded the verbose form.

No discussion.
DF:  Do we accept modified text posted as our text to resolve 171?
Mark:  At end of 1st paragraph, language seems self-contradictory in that
it says SOAP does not mandate schema but a SOAP processor must recognise
xsi:type.
DF: Clarification is that SOAP does not mandate a particular schema
*notation*.
Mark:  Needs to think about it but it is probably OK as-is.
DF:  Hearing no objections, the modified text ([5] in the agenda) is
accepted as the resolution of 171 which is now closed.
DF:  xmlp-comment message about resolution is to be written by Murali. He
should cc Jacek who originated the issue.

7. Issue 173.

DF: On last week's telcon we discussed how to represent fault codes, and
agreed to a hierarchical structure.  Marc Hadley generated schema
declaration for the mechanism. Henrik proposed an amendment to represent
codes as element values instead of as attribute values. Any more
discussion?
Herve: The other amendment was by Jean-Jacques. Rather than put the
fault-code inside the element, make the fault-code be the element name.
Paul:  Does that mean we need to go to an open content model?
DF:  Is there any restriction on the name of the element or content?
Herve: There should be restrictions on top level element, but for other
elements we can leave it open.
Paul:  Microsoft likes the proposal without the changes in [9], and with
Henrik's emendment [8].
Paul:  It makes more sense to use elements.  Microsoft prefers it, and
offers no rationale (in response to a question about their motivation for
using elements from MarcH).
Jack:  Prefers attributes, but would not lie down over the issue.
WG members expressed preferences for attributes and for elements.
John:  Pref for elements.
Noah joined call.
DF: There *appears* to be a preponderance of support for [7] over [8] but
no very strongly held preferences, but I will take an informal poll again
and whichever of [7] and [8] gains a majority will be accepted.

Informal poll shows 6 in favour of [8] and 3 in favour of [7].

DF: issue 173 is closed with [7] amended by [8].  To discharge the issue,
we need to revamp the schema fragment.  Jacek volunteered.  Issue list
maintainers can mark 173 as closed referencing [7] and [8]. Yves will send
resolution email to xmlp-comment.

8. Issue 170.

DF: Our discussion on issue 170 at the last telecon yielded no conclusions,
and taking it to email did not generate any email. The Chair suggests
someone writes a summary of the various positions and put it back to list
to prompt further discussion. The Chair is also open to other suggestions
for moving forward.
Stuart volunteered to write summary thread by end of the week.  No other
suggestions were made.

9. Issue 40.

This agenda item is largely un-minuted because the scribe was involved in
the discussion.

Ray:  I do not think that SOAP is optimized to resource constrained
devices.
Noah: The lack of well-specified requirement makes this issue difficult to
resolve.

Action to Ray Whitmer to propose amendment to "Issue 40 Take 2" [20] by the
end of the week.

10. 144 & 161.

DF: To recap, at the F2F meeting, we accepted a proposal to clarify the
rules of arrays. We did not decide what to do with sparse arrays, whether
to remove them or mark them.  We decided to ping the public on this issue.
Can someone summarise what have we heard back from the community?
Jack:  Summarization of soapbuilders.  Initially, some people said they
would love them to go away.  Then others felt that they were useful in some
cases.  Soapbuilders mostly showed us that on a vote they would prefer to
remove them, because ways have been shown to represent sparse arrays.  But
others wanted to keep them. There was no heavy leaning one way or the other
but slight preference for removing them.  One person said applications
would require redesign. There was at least one person who wanted to remove
it.
PaulC: he does not give it the same weight to people who want to remove
sparse arrays because doing so may not be backwards compatible.
DF:  Our attempt to glean public info appears to mirror our own internal
experience.  We also had members not wanting to lose them due to backwards
compatibility.
DF:  WRT keeping sparse arrays.  A preponderance at the F2F who favored
keeping sparese arrays also wanted to somehow mark them.  There is no
"marker" proposal at this time.
Murali and ??: noted there have been at least two proposals for a marker,
either an attribute or a type.
DF: For those who want to keep them, is the presence or absence of a marker
important?
Murali: A marker would really help.
Jacek: If we go with marker and the marker indicates handling of missing
elements, I think that could address everyone's concerns. An attribute with
3 values:  Sparse array, not sparse, sparse where omitted are null, where
omitted are not present.
Noah:  thinking about sparse versus partially transmitted arrays. Suggest
there be only one concept of an array, fragmentary on the wire.  We do not
have an update model.  We only say what is represented by the message.  The
default is to transmit in its entirety.  It is a warning to the serializer.
Leave it to the higher levels to determine what is there.  If you say it is
dense, then being not dense is a fault.
DF:  Interesting. WG members have previously been in favor of removal, what
do they think of this idea?
Paul:  I can live with Jacek's proposal of keeping them.
DF:  Which proposal?
Paul:  Archived as proposal #122, xmlish serialization.
DF:  Have any other positions changed from F2F?
No one answers.
DF:  Apparently most others have not changed.
Paul: Microsoft discovered we had no one using sparse arrays.
Noah: I was trying to broker a compromise agreement.
DF and Paul thank Noah for doing so.
DF: I'll aks the question again: Does anyone need sparse arrays?
No answer.
DF: Apparently not!
DF: People are perhaps in in favour of the orginal proposal to remove
sparse arrays according to Jacek's original proposal. (DF clarifies that
the "original proposal" is actually contained in dist-app messages, #186 in
November and #92 in November) If a solution can be found in messages #92
and #186, I would like to see these as a single proposal before we make a
decision.  (DF asks Jacek to explain the "original proposal").
Jacek: Array:type changed to array:size, .... [scribe did not record much
of the detail] .... 192 contains simple  explanation of how sparse and
partially transmitted arrays can work even if this passes.
DF: With this rough description, should Jacek go forward and put forward a
single proposal that would include the removal of sparse arrays?

Several people agree and no one voices a concern otherwise.

Action to Jack to put together a proposal by January 4th.
DF: This proposal will be put on the agenda for the next telecon.

11. Issue 168.

DF: There has been a lot of email on this subject, and so Jacek, after
discussion at the ETF offered a suggestion to refocus to resolve 168. The
Chair suggests we can make progress on 168 by accepting the suggestion and
identifying other (related) questions that need to be answered.
Jacek:  Reiterates the suggestion on the thread that no one replied to that
the href attribute can point to anything at all, and it is the
responsibility of the target to provide the type. There was a reply from
Noah who asked about other issues.  Another reply from Henrik that it was
OK.
Noah: The general drift of this is OK. A few specifics make me nervous.  I
am concerned how "type" is used, because of the suggestion it might be
supplied by MIME.  We should think hard about what types are in data
models.  MIME
types?  I don't think so, but maybe.  If only schema types, structs, etc,
this cannot be a back door for expanding the type system.  We should get
our type model straight.
Jacek: MIME types should be mapped to other types.
Noah:  Work on the wording to make sure people do not think that there is a
MIME type of GIF, which we shouldn't do unless we really mean it.
Paul:  General direction is satisfactory.  He is also in favour of HREFS,
not IDREFS.
Jack:  Yes.
DF: The way to move forward would be to take another pass on the text.
Ideally someone should take an action to rewrite the text.
MarcH: does agreeing with this proposal mean that we close a related topic
in which we are debating whether to use HREFs or IDREFs?
Jacek: I do not see it that way. Agreeing to this proposal is only relevant
if we agree on HREFs over IDREFs.
DF:  What is the number of the href versus idrefs issue?
Several: It is not in the issues list.
DF:  Do we have a volunteer to rewrite the proposed text?

No one volunteered

DF: We will take it to email then and pick it up again in January.

DF: Its now time to adjourn the meeting, the next meeting is in 3 weeks on
the 9th of January.