Minutes of XMLP F2F Meeting, Dec 2-3, 2003
Hosted by BEA in San Francisco, CA, USA.
Roll
Present
BEA Systems, Mark Nottingham
BEA Systems, David Orchard
Canon, Hervé Ruellan
IBM, David Fallside
IBM, Noah Mendelsohn
IBM, John Ibbotson
Microsoft Corporation, Martin Gudgin
Nokia, Michael Mahan
Oracle, Anish Karmarkar
SAP AG, Volker Wiechers
Sun Microsystems, Marc Hadley
W3C, Carine Bournez
W3C, Yves Lafon
Excused
Canon, Jean-Jacques Moreau
Microsoft Corporation, Jeff Schlimmer
Oracle, Jeff Mischkinsky
SAP AG, Gerd Hoelzing
Sun Microsystems, Tony Graham
Regrets
SeeBeyond, Pete Wenzel
Systinet (IDOOX), Jacek Kopecky
Absent
DaimlerChrysler R. & Tech, Mario Jeckle
DaimlerChrysler R. & Tech, Andreas Riegg
IONA Technologies, Mike Greenberg
IONA Technologies, Seumas Soltysik
Systinet (IDOOX), Miroslav Simek
Tuesday morning, 2 December
Scribe - Hervé Ruellan
Agenda review
=============
David: agenda focused on MTOM, Miffy, what we have to do to finish those documents.
There are a few issues against MTOM, plus call for new issues.
David: What to do with Attachment Feature. Need to resolve before going to LC.
Check state of MTOM Requirements.
David: Go throught SOAP 1.2 issues. Most of them editorial.
David: MTOM, Miffy reviews: log things that might be issues. One option is to
step throught them.
David: AOB?
Yves: Talk about new charter?
David: OK, tomorrow with errata work.
Approval to minutes
===================
Minutes from November 19 telcon approved without objection.
Action items
============
MarkN - still pending
MarkN, David - still pending
WG - still pending
MarkN & Noah - done
David - done, will do report
David - done
Noah - done
MarkN - done
Hervé - done
Status report
=============
Media type
----------
David: Revised proposal for MTOM media-type was generated
(http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2003Nov/0035.html).
MarkN: Raised an issue: draft say doesn't have to use multipart/related for
packaging, whereas spec headed that way.
MarkN: Could probably leave the text as it is.
MarkN: When using Miffy, probably not a general media-type, but need one for each
application of Miffy.
MarkN: Current registration draft does not refer to Miffy, it is SOAP 1.2 specific.
Noah: Are we confortable with the draft not referencing Miffy?
David: application/soap_mtom+xml media type of whole?
Gudge, MarkN: no, media type of root part.
David (and others): Root part has a soap and miffy specific media type. Other parts
have their own media type. All this in a multipart/related package.
MarkN: There is a req of not using only multipart/related package.
David: Question about how root part media type will refert to Miffy?
David: Text just to explore whether getting a specific media type for root part was OK.
Gudge: Purpose of proposal is to answer a question.
Noah: Express the fact, in draft, that format will be the root for a generic format
for different purpose, because may affect answer.
David: Add sentences in text to reflect this.
ACTION to Noah to do it by tomorrow.
DavidO: Friendly ammendment about why soap_mtom and not content encoding. See second bullet.
MarkN: Closest thing is content transfer encoding and bar very high for registering
it. If new content encoding and looked like multipart/related would raise problems in IETF.
DavidO: Second bullet does not capture those explanations.
DavidO: We have some justification which is not in draft.
MarkN: IETF will say if we don't do the right thing. But we may add more explanations.
ACTION to MarkN to do it by tomorrow.
David: application/soap+xml
MarkN: Need to incorporate text in draft.
David: Queue this for next week.
ACTION to MarkN to reformulate SOAP media type registration for next week.
(closed for AI)
XMLP collaboration on MTOM/MIFFY
--------------------------------
David: Got some response from SVG WG Chair. SVG WG meeting today. Generally positively
interested. Will consider updated specs (those of the agenda). Task force seems to be
a good idea.
David: WS coordination group. Team has been discussing notion of generic mechanism.
Feeling that this work should be made more generically applicable accross W3C technology.
Hugo said "Maybe the core WG should take ownership of this".
Yves: Liam Quin said XML core should look at this work. Different from ownership.
David: Trend: have a task force with member from Core, SVG, ... XMLP point of view:
we don't want to wait too long for this. We have to go on a task force.
Noah: Two different things said: need to go to LC fast, need to go on task force.
How to reconcile this? Using Miffy for other things will raise new problems such
as how to put a Miffy encoded fragment into a SOAP envelope.
David: Still in early stage of formulating how this works out.
DavidO: How to structure this to put it in a time box. Limit time allowed for
doing a generic work.
Yves: There already has been a time limited task force. Mechanism is there.
DavidO: Time limit could reconcile both point of views: ship now or do generic thing.
MarkN: Would like to make our work reusable. Not do something as quick as possible:
there has been already several try at doing attachements.
Gudge: Do it as fast as possible.
Noah: Community is especting to be effective. Think we are very close. If Miffy
raises too much problems, then just drop it. We can always upgrade afterwards to
a new version of Miffy.
MarcH: competitor: WSI attachments. Probably no rush to implement MTOM-Miffy, if
no rush to implement WSI attachments.
MarkN: Should go between the two ends.
David: Think we are close. We could split Miffy and MTOM, and rejoin them later.
Noah: Concern: if Miffy starts to seem as not being close, then stop it. We don't
know well what we're generalizing.
MarkN: Think we just split Miffy and ask feedback about it.
David: Can agree to set up TF, but TF have a limited time to do its work.
MarkN: Think separated as it is brings some value. Even if it is not usefull to
SVG or other as it is.
MarcH: Agree that split is a good thing.
David: If XMLP decides not to open up spec, what would be W3C reaction.
Yves: Depend on the reason. Can argue that representation is transient: will just
exist between two nodes at the binding level.
DavidO: We should try to generalize: either it works or not.
David: Limited expectation (we have a set of requirements), limited time, then we
could consider generalization. On that basis, we would be willing to participate
in a TF. We need to be able to answer the question: "why did not you try to generalize
that?" at LC time.
ACTION to chair to formulate proposal on the condition for going to TF in time
for next week telcon.
XMLP/WSD TF
-----------
Anish: no response from Jonathan. Will ping him on thursday.
ACTION to Anish to ping Jonathan.
-- break --
Evaluation of Miffy
===================
See: http://lists.w3.org/Archives/Public/xml-dist-app/2003Nov/att-0081/miffy.html
David: Go section by section.
1. Introduction
---------------
Noah: last sentence too close to requirying optimization of ALL base64 content.
David: Miffy is 3 things: format, document and processing model. Is this coherent?
Need to be crisper on what it is if we go to a TF.
Noah: Try to say that Miffy take some information, transfert them in a compact
form and is able to reconstruct information. Input and output modeled as data model,
content encoding as XML Infoset. But no clear.
Anish: Terminology, says Optimized Data is removed, while is is said that data is
still in the Infoset.
Noah: Start with some information (data model). Do some transform with this information.
At the end get most information back, minus type information. There is one infoset:
attribute, element, etc. will show on both end. To transfert the information we
prepare a second infoset which do not contain optimized information. Question: was
is the terminology we want to use? Speaking of infoset make sense for optimized data.
Anish: OK, just add a sentence to clarify confusion.
Noah: "Input data model", "reconstructed data model", identical except that reconstructed
data model has everything untype. Reprensentation of this which is an "encoded infoset".
Anish: Consfusion about optimized infoset.
MarkN: Text written before some recent conclusions. Confused by Noah's proposal.
Noah, MarkN: Used Data model as terminology because it allowed to talk about typing.
MarkN: Run through document, remove infoset and check data model is correctly used?
Noah: What is the term for optimized form?
Gudge: three things: start, middle, result.
Noah: What is the second one: infoset, data model?
MarkN: First one, "input data model". Optimization Candidate: ok, maybe some tweak.
Optimized Infoset: call it "Miffy document".
Noah: Neither infoset nor data model. What is it?
Gudge: Go back from data model to infoset everywhere.
Gudge: Miffy document is the serialization, optimized infoset is the root part.
Optimized data is the other parts. We know what they are, need to name them correctly.
Gudge: Root part has an infoset of its own?
Gudge: First infoset present in the serialization as a different infoset + other data.
Noah: This other infoset represented as XML 1.0?
Gudge: What will happen if we make the root part another Miffy document? We've got
something where some base64 optimized in first pass, some base64 optimized in second pass.
Noah: Can image fragments of Miffy content.
Noah: Answer, is no nesting.
Gudge: To put a Miffy content, unwrap it, put it, then optionnally reoptimized everything.
David: Log this as an issue.
Noah: Issue is solved.
Gudge: Do we case about identifying the XML tree which contain the xbinc:include as an XML tree?
Noah: Probably not.
MarkN: Due to several reason, Miffy document is the XML tree which contains xbinc:include.
The "old" Miffy document in the spec is the package.
MarcH: Input DM -> DM + lumps (serialized as doc + lumps) -> DM. Easier to specif
steps from Input DM to middle DM to output DM separately from serialization step.
MarcH: Input DM contains base64 + typing. Middle DM contains xbinc:include. Output
DM contains base64.
// MarkN draws diagram of this.
Anish: Middle DM has typing info?
Noah: Everything is untyped in middle DM.
MarcH: Difference is already went through serialization or not.
Noah: On an implementation point of view, type may be here, but on specification
point of view, just say that middle DM does not have any type information.
David: This diagram should also have infoset in it for other WG.
MarkN: Do not see value of talking of DM for Middle DM. Keep chart as simple as
possible with has few terms as possible.
Noah: W3C has several overlapping terminology: XPath, Infoset, Data model. Problem
is to adapt specification written before.
David: Does it make sense to have both DM and Infoset in each box of the diagram.
MarkN: Should not try to solve architecture problem.
Noah: Why start with type info and lose them. Because SOAP is untyped.
Gudge: Input and output thing because thinking in term of SOAP binding. Think about
constructor and deconstructor.
Gudge: Mechanics for describing this are going more complex, and don't see the reason.
Gudge: We have to say something about input data. Why not just say it is canonical base64.
David: We leaved the possibility of optimizing other things than base64.
Gudge: In this case, we need type information.
Noah: Data model says whether you start with typed value or string value. In MTOM
as the base64 is canonical, the transmission of the typed value is sufficient.
Gudge: Don't disagree that we can use DM to describe our spec. Discussing about
having 3 DM in diagram.
MarkN: Map terms with diagram.
David: Input DM and Output DM have same *Infoset*.
Noah: Infoset not typed, but Input DM has some type information. If start with
Infoset, need to find the type information.
David: Proposal remove Infoset from diagram.
David: In document need to be discussion about infoset relation with input DM.
Noah recapitulation of decision: Write text to explain the diagram. In particular
explain the case where the input data is an infoset and the case where the input
data is already a data model.
MarkN: Input DM is *Original DM*. Output DM is *Reconstituted DM*. Middle box is
*MIFFY DM + Extracted Content*
MarkN: Encoding is *Extraction*. Decoding is *Reconstitution*.
Diagram: [Original DM] --Extraction-> [MIFFY DM + Extracted Content]
--Reconstitution-> [Reconstituted DM]
Diagram: [MIFFY DM + Extracted Content] <-Serialization/Deserialization->
[MIFFY Package = MIFFY Document + Extracted Content].
Noah: What is extracted content? Proposal that it is mime-typed streams.
Tuesday afternoon, 2 December
Scribe - Volker Wiechers
Afternoon session I
Evaluating Miffy [1]:
Discussion on terminology continues.
Optimization Candidate:
MarkN:
things about three models for identifying optimization candidates (OptC)
o by type info within the data model approach
o by an external list
o by some magic hidden to the MIFFY processor
Discussion of pros and cons for external data for identifying OptC.
NoahM proposal: Use some external description like XPath, node list ...
to identify the optimization elements.
MarkN proposal: Just use the type information within the Data Model (DM) for identifying OptC
The WG decided not to use an external list but to use data type information to identify OptC.
1.3 Terminology
MH: Title of 1.3 is duplicate of 1.1
DF: Suggestion: move text from section 1.3 up to section 1.
After some discussion how to rephrase section 1.3 mainly paragraph 3, the WG
decided to assign an action item to MarkN to reword section 1. The WG will then
reinvestigate the changed text.
2 MIFFY
DF: Text will change. Discussion after rewriting.
2.1 MIFFY Multipart packaging
MH: Change order, section 3 before section 2.
DF: Goto section 2 and then come back to this discussion.
DF: Comments on 2.1?
MH: Should the multipart mime stuff be in a separate section?
DF: Makes this any difference?
MarkN: Will help to introduce different packaging (could be done in the appendix)
An action was assigned to Yves to check how the different versions of XML are
effected (xml1.1)
2.2 Optimized Infoset
Noah: SHOULD in the second part of the first sentence should be changed to MAY.
DF: We could simply delete second part.
The deletion was accepted by the WG.
2.2.1 xbinc:Include element information item
Gudge: Definition is incomplete, because it should not allow other children either
Noah: Reference to the DM spec. This will give you a deep knowledge
what is allowed in this context.
The WG assigned an action to Noah to explain which children are allowed for the
xbinc:include with regards to the DM.
2.2.2 href attribute information item
MH: Did we say anything about relative URIs?
Gudge: We can say that all URIs must be absolute
Noah: The DM gives a base URI property for all elements.
MarkN: Should/could we restrict URIs to CIDs?
Discussion how and if we must establish base uri semantics/base uri processing
for MIFFY.
Anish: supports a CID only approach
Gudge: We have several types of URIs. URIs for MIFFY are gone if
we reach the SOAP processing level. So we can simply make them
global.
Anish: If we don't want to support caching, CIDs work fine
Noah: Lets identify, if we can make it simple (omit caching etc.)
Noah: The href must name the content id not the content location.
Discussion if CIDs could be relative or hierarchical.
DF proposal:
Identify extracted content with a CIDs, implementations MAY
adorn with Content-Location, if that information is available
The proposal above was accepted by the WG.
MH: Drop last bullet or be more specific
o Other accessors such as dm:parent MUST be set according to the context
The WG decided to leave the list as is.
2.2.3 href attribute information item
Anish: depends on TF with WSD group.
DF: Leave section 2.2.3 as TBD.
The proposal above was accepted by the WG.
3. MIFFY Processing Model
No change here.
3.1 Creating MIFFY Documents
MH: bullet 3 of 2.3
... "If the parent element information item of the Optimization
Candidate has a mime:content-type attribute information item,
its value SHOULD be identical to the field-value of the MIME parts
Content-Type header field."...
Proposal:
Change objective: Content-type and other MIME meta data are set according to
application knowledge
The proposal above was accepted by the WG.
3.2 Interpreting MIFFY Documents
Anish: Add a ref to the RFC that defines 'root part' of MIME Multipart/Related
4 Selecting Optimization Candidates
MH: Is hiding the information that a message is broken the best approach?
... "If an optimization candidate cannot be successfully encoded into the
optimized infoset, implementations SHOULD behave as if that portion
of the Target Infoset were not identified as an optimization candidate." ...
The introduction of section 4 may be moved to the introduction.
5. Identifying MIFFY Documents
[TBD, depending on media type feedback]
No changes here.
Noah: We should state clearly that Miffy is defined only on Miffy Packages
and documents that conform to the rules set out in this document. Typically,
software presented with a non-conforming MIFFY document SHOULD reflect an error.
6. Security Considerations
[TBD]
No changes here.
Afternoon session II
Evaluating MTOM [2]:
1. Introduction
MH: Does the second paragraph make sense (with respect to SOAP modules)?
... "This Abstract Transmission Optimization Feature is intended to be implemented
by SOAP bindings, however nothing precludes implementation as a SOAP module."
Proposal: Drop paragraph.
The WG accepted to drop this paragraph.
NoahM: Proposal: Reinsert the deleted second paragraph starting with:
"Unlike SOAP itself ..."
The WG accepted to reinsert the deleted paragraph
DF proposal: Remove the whole last paragraph starting with
"This document represents a ..." after resolving open issues 442 and 443 [3]+[4]
The proposal above was accepted by the WG.
1.2 Relation to other specifications
MH: Last sentence of first paragraph starting with
"However, it may be expected that ..."
Should be fixed before going to last call.
Noah: Section 1.2.1 was a major part and is now crossed out.
We need to revisit 1.2 after we have decided how to proceed
with 1.2.1 (see below)
Proposal: Leave the deleted section starting with: "See 1.2.1.." out.
The proposal above was accepted by the WG.
Noahs proposal:
Reinsert deleted section 1.2.1 maybe after some cleanup
The proposal above was accepted by the WG.
1.2.2 Relationship to the SOAP Processing model
Proposal: Remove editorial note of 1.2.2
The proposal above was accepted by the WG.
2. Abstract Transmission Optimization Feature
2.1 Introduction
Proposal: First paragraph: change "re-encoding" to "encoding"
The proposal above was accepted by the WG.
Discussion on the second deleted paragraph staring with:
"The Abstract Transmission Optimization ..."
Noah: Where is the appropriate place within the spec to
describe this and how?
Discussion on
o how the processing model could be described
in a way that is helpful for implementers,
o how we can identify the optimization part
(enhancement of the morning discussion about this topic),
o how the data model and info set approach could be combined,
o how MTOM and MIFFY are related ...
Proposal: No changes (leave the second paragraph crossed out)
The proposal was accepted by the WG.
2.2 Abstract Transmission Optimization Feature Name
??: Should "Feature Name" be changed to "Feature Identifier"
2.3 Abstract Transmission Optimization Feature Properties (deleted section)
No change. The section was left as deleted.
2.4.1 Sending a message
Noah: How much must we say about enabling this features here?
MH: Use the MEP properties/mechanism to reformulate 2.4.1 and 2.4.2
A) Proposal:
1) Delete the mentioning of enabling features etc.
2) Proposal for inserting references to section 6 of SOAP 1.2 part 2
where appropriate
3) Describe how the sender generates the data model which contains type
information on some nodes and how this type info is used to determine
what is optimized
4) Describe how the Receiver generates a data model where the nodes have no
types
The proposal above was accepted by the WG.
B) needs volunteers to do this
An action was assigned to Herve to generate text for 2.4.1 and 2.4.2 with support of JohnI.
2.4.2 - 2.4.4 (Receiving a message / Binding Optimizations at Intermediaries)
MH: The MIFFY spec should explicitly say how to reconstruct the DM, then
point from 2.4.4 to the MIFFY spec.
DF proposal:
1) Change MIFFY in a way that it is lossless regarding to the DM type info
2) The only DM type information in MIFFY is base64Binary
The proposal above was accepted by the WG.
3) relate 2.4.4 to MIFFY
The WG decided to do this later.
4. HTTP Transmission Optimization Feature
4.1 Introduction
Gudge: Green paragraphs seems to be redundant.
A discussion started how to rephrase section 4 in conjunction with section 3.
Proposal:
o rename section 3 "Inclusion Mechanism" to "MIME Multipart/Related Serialization".
The content of the new section will describe the construction of the DM
and the parsing to MIFFY
o revert Section 4 to its previous wording (reinsert green and delete red paragraphs)
The proposal above was accepted by the WG.
A. Mapping between Infosets and Data Models
Proposal: Revisit appendix A when new wording of section 3 and 4 is available.
The proposal above was accepted by the WG.
An action was assigned to MH to propose how to link section 4 to SOAP 1.2 part 2
[1] http://lists.w3.org/Archives/Public/xml-dist-app/2003Nov/att-0081/miffy.html
[2] http://lists.w3.org/Archives/Public/xml-dist-app/2003Nov/att-0077/OptimizationMechanism-25-11-03.html
[3] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x442
[4] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x443
Wednesday morning, 3 December
Scribe - Noah Mendelsohn
==============================================================
Started 9AM
Reviewed revised agenda:
http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2003Dec/att-0006/agenda.html
Proposal: cancel telcons 12/24 and 12/31. Agreed without dissent. Next telcon is January
Action: Marc H. to provide some samples by which group can judge direction on
linking section 4 in MTOM to existing terminology in SOAP 1.2 part 2" Due start of business 12/15.
--------------
Start discussion of SVG comments on Miffy:
http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2003Dec/0003.html
They raised 4 points:
* Referenced parts must include the 'Content-Transfer-Encoding' field and should
include the 'Content-Length' field.
* The referencing mechanism via 'Content-Type' and 'http' URI presents an ambiguous
referencing mechanism and may require removal.
* Addressing the 'data:' URI directly in the MIFFY specification is desirable.
* Packaging multipart payloads via use of the 'multipart/multiplexed' mechanism
in RFC 3391 should be considered as a valid MIFFY encoding mechanism.
DF: let's log these as 4 issues
ACTION: Carine to verify with Chris Lilley we can discuss in public space, and
if so open 4 issues
Begin discussion of suggestion that: Referenced parts MUST include the
'Content-Transfer-Encoding' field
and should include the 'Content-Length' field.
MNot: I think they're right alternative would be to respecify MIME, we don't want
to do that.
Noah raised several questions:
* Do we need to run on non-8 but clean channels, they seem to imply that. Gudge:
you misunderstood, the reason they are requiring Content-Transfer-Encoding binary
is to warn that the resulting package will not be 8 bit clean. Noah: OK
* Doing lengths in advance can be a problem. Several people: yes, that's why they
say SHOULD. Would that be OK. Noah: I suppose, let's just say clearly what we're doing.
Mnot: I'd like to review the issues here.
ACTION: Mark Nottingham to review on telcon of 12/10 the issues relating to
content-transfer-encoding and content-length
2) The referencing mechanism via 'Content-Type' and 'http' URI
presents an ambiguous referencing mechanism and may require removal.
We believe this issue is pre-emptively resolved by yesterday's decision to use CID: only.
3) Addressing the 'data:' URI directly in the MIFFY specification
is desirable.
MNot: data: scheme lets you put data into a URI. This would be a different
encoding. Hard thing is they want to use these in attribute values.
Proposal is: recognize data:xxx in the value of an attribute or element.
Gudge: what about looking at their multipart/multiplex proposal first
OK
4) Consideration of packaging multipart payloads via use of the
'multipart/multiplexed' mechanism in RFC 3391 should be considered
as a valid MIFFY encoding mechanism.
Inconclusive discussion of details of what's intended.
DF: let's leave this for awhile and move to other things.
ACTION: Mark Nottingham to send kickoff email to protocols member list to start
discussion of points 3 and 4 above. Due 12/5.
ACTION: David Fallside to update Chris Lilley on our action plan for SVG issues.
End for now discussion of SVG issues.
--------------------------------------
Discuss Noah proposal at: http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2003Dec/0001.html
Proposed text is:
<proposed>
Note that a specification is being prepared that allows for the use of a
similar "resolve the URI to insert binary characters" idiom in non-SOAP
scenarios. The general technique is documented at [2] under the working
title "MTOM Inclusion Format For You (MIFFY)", a title that will almost surely change
due to copyright issues. The
proposed application/soap_mtom+xml media type is thus a specific example of the
so-called Miffy class of
encodings. We propose that a media type be assigned to each such use of
Miffy, with application/soap_mtom+xml being assigned as the name for the
application of Miffy to SOAP envelopes.
</proposed>
Accepted without dissent.
Mark Nottingham has proposed other text in the same area. Let's discuss. See:
http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2003Dec/0007.html
Mark writes:
--
I propose that we replace this:
> We've considered several possible alternatives, and currently believe
> that it would be most suitable to register a new media type, e.g.,
> "application/soap_mtom+xml". This media type would identify the XML
> pre-MTOM processing (i.e., with the URIs to be referenced still
> embedded), possibly (but not necessarily) located inside a
> multipart/related package.
with this:
We've considered several possible alternatives, including 1) use of a
HTTP content-coding (which we rejected, both because content-codings
are a HTTP-specific mechanism, whereas we intend to use this encoding
in other protocols, possibly including MIME-based protocols, and
because doing so would require labelling the HTTP entity with an
"application/soap+xml" media type, which would mask the presence of
multipart MIME), and 2) a MIME content-transfer-encoding (which we
rejected because registration of new CTEs is discouraged by RFC2045).
Therefore, we believe that it would be most suitable to register a new
media type, e.g., "application/soap_mtom+xml". This media type would
identify the XML pre-MTOM processing (i.e., with the URIs to be
referenced still embedded), possibly (but not necessarily) located
inside a multipart/related package.
--
Mark's proposed text is accepted without dissent. These decision resolve Noah's
and Mark's action items.
DF: I think this resolves pending issues, can we send this to IETF.
Mnot: Do we send to liaison only or IETF types list?
ACTION: Mark Nottingham to edit the note and send to IETF liaison mailing list. Due 12/5.
--------------------------------------
Discuss Noah proposal at:
http://lists.w3.org/Archives/Member/w3c-xml-protocol-wg/2003Dec/0001.html
for DM formulation of xbinc:include.
dm:base-uri, agreed
dm:node-kind
dm:node-name: change to use {uri;include} syntax.
dm:parent
Change to say "the sequence containing exactly one element node, that being the
parent of the xbinc include element"
dm:string value:
Change to the empty string
dm:typed-value:
Return (), the empty sequence.
( By the way, Noah accidently gave string-value and typed-value, and type for the
href attribute...We can move that text there.)
dm:type:
We need to define a schema type and use it.
ACTION: To Gudge to generate schema for xbinc:Include and friends. Due 12/5.
dm:children
Return (), the empty sequence.
And we will put a note in the spec to invite comment.
Some discussion from Marc Hadley of what to do with errors.
Noah suggestion: in building this when serializing, the above should be true by
construction. On deserialization, I think we should say: any XML that deserializes
to a DM that does not meet these constraints is by definition in error.
dm:attributes
Returns the value of the attributes property, which must contain a single
attribute node representing the xbinc:href attribute.
FIX the above: the href attribute is unqualified.
Some discussion of whether to allow additional attributes for versioning.
ACTION: David Orchard to send note to xmlp-comment opening issue to discuss MTOM/Miffy
versioning.
dm:namespaces
Returns the value of the namespaces property. The namespaces defined must
include at least one definition which has as its URI property the {xbinc
namespace URI here}, so that the include attribute can be serialized. That
definition may but need not be for the default namespace.
Change the above from "the include attribute can be serialized" to "so the include
element name can be serialized"
ACTION: Gudge to do for the href attribute what we've done here for the include
element, i.e. put in DM terms. Due 12/5.
ACTION: John Ibbotson to draft feedback on utility of DM spec. Due COB 12/8.
===========================BREAK====================================
Discussion of Issue 440
http://www.w3.org/2000/xp/Group/xmlp-issues.html#x440
Proposal to split discussion:
a) unrefed parts
b) shared parts
Marc Hadley: we should allow unreferenced parts. We should allow applications
to use this for their own purposes. We don't even need to say anything about it.
Gudge: I could live with it, but only if not visible at the SOAP layer
Noah: Proposal a) at Miffy level, allow unrefed parts but say user must indicate
whether they are allowed and if so what significance is b) at MTOM serialization
say particular bindings can allow or disallow, and must specify interpretation
c) in our HTTP binding, DISALLOW.
Volker: do we have to preserve these parts at intermediaries?
Noah: good point.
Gudge: make clear that intermediaries can drop them
Gudge: I can live with extra parts or can live without.
Proposal from Gudge: Allow unreferenced parts in Miffy, in the MTOM serialization,
and our HTTP binding, but indicate that for all SOAP uses this is outside the SOAP
model, may not be supported by the next hop, has no well-defined intermediary model. etc.
Agreed without dissent: this is the direction we will pursue.
ACTION: Gudge & Marc H. to generate proposed text on ureferenced Miffy parts by COB 12/12
Now discuss sharing of parts in a Miffy of serialization.
Marc H: yes, allow it. It's just a further optimization and a good one. I made
a proposal for how to surface the IDs into the data model to process with normal
SOAP rules. Would be willing to drop that and leave as exercise to the implementaiton
to notice same content in two places.
Gudge: disagree, I want to be able to drop a part once it's been used, thought
admittedly that will only happen when the order of parts happens to be more or
less application order.
Noah: I'm very concerned about reference counting at the intermediaries
Anish: would it help to make a header with the counts
Noah: maybe, but I think it's still too complicated. I still vote against sharing
parts, but if we decide to go that way, then we should consider your header proposal.
Gudge: I share Noah's concerns regarding intermediaries.
David Fallside: I'm still nervous about this. Does it make sense to say no for now,
but if we learn from applications' experience, we could make a compatible change later
based on that experience.
Marc H: Don't think so, deployed software won't do the right thing if it's expecting 1-to-1
Noah: agree, we need to take our best shot now and live with that for the forseeable future.
DF: on each side, can you compromise or is this "lie down in the road".
Marc H.: 90% toward lie in the road in favor of sharing.
Gudge: my whole body against
Mark Nottingham: I'm leaning against. Not sure we need a standardized way. Could
eventually get there somehow if needed.
Noah: 91% against.
Herve: on receiver side, having to keep parts around may be a problem. Would really
prefer 1-to-1.
Volker: would like to delegate to application level, but can understand arguments
from Marc about difficulty of changing later. Net: 60/40 in favor of 1-to-1
DaveO: no opinion.
Anish: everyone's saying do at app. level. I have opposite view due to interop.
I'd rather have a standard way rather than each app on it's own (Gudge interject:
represenation header? DF: don't discuss now ploease). Preference is for sharing.
John I: see Noah's IBM answer
Carine: want to see standardized. Probably agree with Marc. Do it in the serialization.
Sort of 50/50 weak preference.
Yves: it's the apps responsibility. Vote for 1-to-1. Moderately strong preference.
Michael from Nokia: not on the phone.
DF: we have to decide whether it's worth continuing discussion. If so, we can find
a structure for discussion. Other pass is we can take a vote, will probably go 1-to-1,
there will likely be a lie down in road objection, which we'll note and move ahead.
Those seem to be our choices.
DF: Question, should we keep going? We've been at it for awhile. Is there a third path.
Noah asks Marc: how common is this?
Marc: maybe not in SOAP, but in other uses of Miffy.
Noah: Aha, is there a compromise where we allow in Miffy but not in SOAP serialization?
Marc: Might be. I need time to think about it.
ACTION: Marc Hadley to consider whether allowing sharing in Miffy but not in SOAP
would be an acceptable compromise. Due 12/10.
-------------------------------------------
Discussion of issue 442: http://www.w3.org/2000/xp/Group/xmlp-issues.html#x442
This has to do with carrying MIME metadata (headers) in Representation headers.
Mark Nottingham: there are a lot of subtleties. HTTP headers and MIME are similar
but not the same thing.
DF: Is there a synthesis?
Mark: could but haven't yet.
Noah: let's please be careful to distinguish use cases from proposed mechanisms.
Mark Nottingham: good point, I've had discomfort about what problem we're solving.
Big issue is: is this web representations in general, or http specifically.
Anish: do we prohibit someone from doing a real get from Google.com, putting the
result, headers and all, in a MIME part.
MNot: That's on OK think to do if it's right from the wire. Some headers would
be connection-specific and make no sense.
MNote: let's just do it at the MIME level
Noah: does this meet our SwA-inspired use cases?
MNot: yes I think so, they do it at the MIME level anyway. Maybe add a flag
governing web-resolution rules.
ACTION: Yves generate a motivation and design for the header heretofore known as
representation. Due 12/9
Wednesday afternoon, 3 December
Scribe - Martin Gudgin
Issue 443: Media-type information for binary data
MarkN: There is the issue of how to represent a MIME entity in
XML. And then there is the issue of how do you associate a media type,
which is type information with particular data. If we did allow data:
URIs in MIFFY then we would have to deal with how to associate media
type information with attribute value as well as element content.
DavidF: Do we agree with Jacek's requirements here?
MarkN: Number 1 is reasonable, number 2 seems fairly simple, in that
you could restrict the value of say, an attribute. I'm wary of number
3 if it goes beyond restricting to a list of types.
Noah: Is number 3 about schema?
Marc: Can you have multiple representation headers for the same
resource but with different media-types?
Anish: I don't think we've considered that.
Mark: That would allow content negotiation. I don't think we've
considered it. You would end up re-implementing content-negotiation in
XML.
Marc: Should we create an issue.
DavidF: Sounds reasonable. New issue is:
Can a message carry multiple represention headers with the same
value for 'Content-Location'
Noah: We should explore the design space.
DavidF: Need someone to send mail to xmlp-comments.
Marc: I'll do that right now.
DavidF: We'll resolve that issue when we see the proposal from
Yves/Mark. Back to 443
Gudge: Is this just about the Representation header?
Mark: No. We need a means of driving the population of the
Content-Type MIME header when we serialize out to the MIFFY
package. We want to say that you will use this attribute to populate
that MIME header.
Noah: Requirement is a bit strong. We're encouraging people to program
in a particular idiom. Encouraging people to type the data is a good
thing. Taking a run at specifying type information is fine, but I
think it should be seperate spec, possibly not owned by this group.
Mark: So we'd have something that would be generally applicable to
XML.
Noah: Is there a timing issue?
Anish: Jonathan did reply and say it would be discussed on the WSDesc
call this week.
Noah: Why WSDesc? Why not XML Core? Seems odd that something in the
instance should be defined by the WSDesc WG.
Mark: Should we write up a prefered approach and submit it to the
joint task-force.
DavidF: The timing thing is an issue.
Gudge: We could de-couple from MIFFY/MTOM and have the media-type spec
state that it is one way to provide information to MIFFY/MTOM.
Mark: We could close 443 if/when the task force comes up with a
solution. I'd be tempted to join the task force and driving a proposed
solution and seeing if WSDesc likes it.
Anish: We can figure out what we like and present it to the task
force.
Mark: We can either do that now as a group or Anish and I could put
together a proposal.
DavidF: I think coming up with a proposal would be good. Would Anish be
amenable to coming up with a proposal to present to the WG?
Mark: Should Anish just pick one from the list Jacek enumerates?
DavidO: We could enumerate the solution space and then recommend one.
DavidF: I assumed we would generate a proposal and take it to the
WSDesc task force.
Mark: Are we discussing this now? Or offline?
DavidF: I would think offline. I'd prefer Anish to draft something and
then noodle on it.
DavidO: The reason I suggested that we enumerate the solution space is
to short-circuit the discussion once we make a concrete proposal.
David: Anish, can you do such an analysis and make a specific
proposal?
Anish: Yes, I can do that.
David: Would it be useful to spend 10-15 minutes discussing it now?
DavidO: I'd prefer a bit of discussion now.
David: Time-limited discussion. 15 minutes max.
Mark: p:MediaType attribute in the instance. Value would be a
media-type e.g. image/jpeg
Anish: Can you have parameters?
Mark: Need to address that issue regardless of proposal. Is it really
a media-type or a content-type.
Mark: xsi:type='image:jpeg', mapping qname to media type
Mark: p:MediaType='cturi:image/jpeg' where attr value is a URI. Is
this MediaType or general type? Only difference between this approach
and the xsi:type approach is this one uses URIs and xsi:type uses
QNames.
DavidO: Is this cturi: something IETF has been working on?
Mark: Yes, Eastlake has been working on it. Some movement to
urn:ietf:.....
Gudge: Like the p:MediaType='image/jpeg' approach, hate the other two.
Noah: Can someone please tell me what the benefits of approaches two
and three are?
Mark: Approach 1 is specific to media types. Approach 3 is more
general and might be applicable to other type systems. You wanted to
use this outside of SOAP.
Noah: It seems reasonable to allow MIME typing in a general fashion
in XML. Don't want to make it more complicated than it needs to be. It
should also be possible to say in a schema that a given field is
base64Binary and that it should be image/jpeg. I should be able to
make a schema subtype that restricts the attribute to a fixed
value. Think both one and three allow such a schema approach.
Mark: I have an ulterior motive. I want to stop using QNames to
identify types and use URIs instead.
Noah: Might want to define a 'jpeg' type ( which has the restricted
attribute value ).
DavidO: We asked the OASIS WSS TC to use URIs instead of QNames in
their spec.
Noah: Proposal 1 is not QName based it's string based.
Mark: Using URIs for typing makes things decentralised ( breaks
dependency on registration of media types with IETF ).
Noah: But today I have to use image/jpeg, not urn:ietf:...
Mark: At the mime layer you use image/jpeg at the level of XML you
would use urn:ietf:...
Marc: In some cases there is a benefit to having a dependency on IETF
Mark: Can already register new media-types using x- but no way to
disambiguate.
Noah: I think for what you want media types are more broken than this
is fixing....
DavidO: So you think 1 is more appealing because it uses a structure
that already exists whereas 3 starts us down a path which might not
address all the problems.
Noah: It has the downside of promoting a second set of names.
Gudge: I don't think 3. is something this WG should do.
Anish: I heard people talking about urn: schemes. Did anyone look at
the tag finding which proposed using http: URIs -
http://www.w3.org/2001/tag/2002/01-URIMediaType-9.html
DavidO: I mentioned it to Eastlake but the IETF declined to to use
http://iana.org
DavidF: We are time-limited. Do we have a preference as a group?
Mark: I heard Gudge say it should be simple, in which case maybe we
shouldn't produce something that's general to XML.
Noah: My concern is reduced if the mapping between URI from and
image/jpeg is deterministic.
Mark: I see one as pretty, 3 as not quite a pretty. 1 has the
bottleneck, 3 has no bottleneck.
Marc: Is this mapping automatic using cturi: or urn:?
Mark: Different forms of the same thing.
Noah: Could kluge with a union type? URI and image/jpeg form?
Anish: My reading of the TAG finding was that the TAG has a strong
preference for the URIs to be deferenceable but the IETF has said
no. Given that TAG has expressed a strong preference, does this affect
our decision on 1 or 3? Or does it not affect it?
Mark: It might affect the URIs we choose.
Anish: But surely we have to use the URIs defined by the IETF.
DavidO: We have to live with what IETF decided. I don't think the TAG
would pay any particular attention to which way this group
decides. Certainly would not expect TAG finding to influence decision.
Marc: If we decide that it's not something we should do, what are the
timing issues?
Some discussion about how coupled/decoupled we are from which
spec defines media-type information for elements whose content is
base64.
Noah: Options for MTOM are
1. It's always app/octet
2. If you have more detailed info, set the content type
accordingly. Information is dropped on deserialization.
Mark: We went there yesterday. We said you could populate the MIME
headers using any information that is available to you.
Marc: surprised because expected everything to be in infoset
Noah: Downside of decoupled approach is that implementations will be
passing untyped data.
Mark: I prefer to decouple and have something generic rather than have
something specific to our spec.
Anish: Need to make sure it's describable by WSDL
Noah: Must be able to assert that an element has base64 and carries
image/jpeg. Must also be able to 'infer' using default/fixed.
DavidF: Just to go back to something Gudge said. Do something simple.
DavidO: We seem to be suggesting that we'll ship something which will
almost immediately be obsolete because some other spec will come out
after we ship.
DavidO: We'll have to be somewhat 'late-bound', waiting for the task
force. If the schedules line-up, great. If not, re-evaluate.
DavidF: There is a shadow issue, implement late-binding ( re-evaluate
based on schedule ). Was there any schedule discussion with WSDesc?
Anish: There were some e-mails about schedule but I can't remember the
details.
Anish: We defined the requirements and we approached WSDesc. We could
say 'we want this in the instance' it's WSDesc job to describe it.
Noah: We need something in time frame X. If we don't get something by
date X, we'll ship something that reminds you of SOAP. If someone else
develops a simple mechanism fine. If they like our proposed mechanism,
fine.
Mark: Hope if we choose option 1, we'd say this is one way of doing
it.
Noah: I don't like that, I think there should be one way of doing
this.
Mark: Then I don't think we should do it at all. Is identifying
media-types something we actually have to deal with?
Noah: If it was me, I'd bake it in to every layer.
Some back-and-forth on whether a standardised approah is needed.
Mark: Can do it at the application level. Nothing stops you doing
that...
Mark: If we do restrict it to just one what if we sometime in the
future move away from media types as we know them today?
Noah: In the future, we might need to migrate, fine. There will be two
ways. But there will at least be one way to begin with.
Mark: If we did it now here, it will raise the cost for doing it
'right' in the future.
Anish: If we do it now, all we're saying is that in MIFFY we use this
attribute value to determine the media type. Some other approach could
be used at the application level.
Noah: Once we ship, either people will ignore it or everyone will
implement this mechanism.
DavidF: Mark you have doubts that option 1 is the right approach.
Mark: Long-term, yes. If we do option 1, we need to leave it open to
another mechanism in the future.
Noah: What I'm saying is that we shouldn't focus it only on MIFFY. I
need to have it in my 'real' data ( purchase order ). Needs to be more
general.
DavidF: So your suggestion is that we tell WSDesc that we have chosen
a given attribute, option 1. Does WSDesc have a preference?
Gudge: Don't think WSDesc has made a conscious decision. General read
is that option 1 is acceptable but WSDesc WG probably not thought
about it deeply.
DavidF: one way forward is to go to the task force and say we want
something that is simple and generic.
Gudge: Why would task-force be better able to choose between 1 and 3
than the XMLP WG.
Anish: The task-force will probably be mainly XMLP folks.
Mark: Is this an issue we should punt to the TAG?
DavidO: Could say to the tag: "This could be considered to be new information
(RFC3553). We're not sure the TAG guidance is still valid"
DavidF: When could TAG look at it.
DavidO: We could give TAG a deadline. Would probably look at it in
January. TAG has responded to time-based pressure in the past. Finding
is now out-of-date. I will ask the TAG to update it.
ACTION: DavidO to draft e-mail to TAG on media typing attributes. Due 2003-12-05.
OASIS WSS TC question
DavidO: Thought I sent mail to the WG this morning but has not yet
gone out. David reads from his e-mail...
Some discussion on mustUnderstand as it relates to wsse:Security and
the content thereof.
Discussion of Attachment Feature.
Mark: Park it.
Gudge: Concur.
DavidF: We can retire the docuemnt ( there is a specific status for
this now on the TR/WG page ).
DavidF; Any objection to parking the document? We can still use
portions of the document.
None heard.
DavidF: propose we will park the attachment feature document when we
go to last call. Any discussion? Any objecttion.
WG has decided to park the Attachement Feature WD at the time that we
submit the attachment specifications to last call.
Discussion of Use Cases and Requirements
DavidF: Do we think this document is about there?
Mark: We should probably go through it one more time after we've baked
MIFFY/MTOM some more
DavidF: So proposal is to evaluate requirements in light of
MIFFY/MTOM. Previously we have tasked someone with doing such an
evaluation and then the WG formally agreed that the requirements had
been met.
Michael Mahan volunteers to go through the Use Cases and Requirements
document.
DavidF: Go through current MTOM/MIFFY and the Use Cases and
Requirements document and come up with a list of places where we do not
meet the Use Cases and Requirements.
Michael: So list of deltas is currently empty?
DavidF: You'll be generating the first pass at the list of deltas. It
would be useful to have this going into the New Year.
ACTION: MichaelM to produce a list of deltas between Use Case and
Requirements Document and MIFFY/MTOM by 2004-01-06
Discussion of Primer
DavidF: Should we have some primer material
Several voices say 'Yes'
Noah: I think MTOM says stuff about bindings and messages. Obvious
stuff for primer would be instructions to people wanting to transmit
base64 binary data. We should tell people how to use MTOM/MIFFY to
create SOAP messages. We *might* want to have a primer on the bindings but less critical.
Marc: We need to be clear that the base64 is a logical detail, that
binary goes on the wire.
DavidF: Do we want a new primer or to modify the old primer?
Anish: How can we update the existing primer?
DavidF: Primer is non-normative, I think we can update it reasonably
easily.
Noah: Some value to having it all in one place.
DavidF: Seems to be concensus to put this info into the existing
primer. Nilo said he could do more work on the existing primer.
Agreed: We would like primer text. We would like it to be in the existing
primer. We will ask Nilo if he can do it and when he can give us an
outline.
ACTION: DavidF to contact Nilo re: Primer text on attachments. Due
2003-12-10.
Discussion of schedule
DavidF: Most critical point in terms of schedule is our relationship
to WSDesc. In going forward with MTOM/MIFFY we want WSDesc to be able
to describe MTOM/MIFFY. In order to do that, they would like a stable
spec by early March 2004. Next stable document is LC document. This
seems like a logical way of coming up with a schedule. Laid out the
twelve weeks between now and end-Feb. Gives us 10 telcons between now
and end-Feb.
DaveO: WSDesc meeting week of 2004-01-26
DavidF: Would have a big review and generate comments and step through
in next couple of telcons. Editors make changes and then have a quick
sanity check review and maybe have a smaller set of edits and editors
put in boilerplate etc. Would need docs ready for review by
2004-01-30. Review would then happen in February. Task force activity
with SVG et.al. will have to happen in January. We have a couple of
issues that we haven't resolved. It's fairly tight. Especially the
cross-WG interactions.
Noah: It's practical from a WG perspective. Cross-WG might make it
hard.
DavidF: Should we go back to SVG/Core and tell them our
schedule. Think SVG will be fairly happy ( we've decided on
Content-Encoding/Length and CID ).
Marc: If we're going to do the Task Force thing we need to give it two
months minimum.
Noah: I'm nervous about the generalization. It will take time to agree
on requirements and use cases. Seems like it would take 2 or 3 months
just to agree that.
Mark: Thought we'd agreed that we were NOT going to try to meet
everyones requirements.
Noah: I didn't realise we were going to do joint work with
SVG/Core. What are the goals of the joint work. Seems to me it might
take a long time.... May need to wait for binary XML etc. etc.
DavidF: What we discussed yesterday was that the CG thought what we
were designing could be useful to others. So we should look at
collaboration. I expressed schedule concern. CG was silent.
DavidF: We could ask WSDesc for another month.
Noah: I'm more worried about getting agreement between the groups.
DavidF: Another spin on XML Core, they are woefully lacking in
resource, they may say they don't have time to devote to it. Does W3C
have any insight into the options.
Yves: The involvement of core is just to generate interest in doing
something general afterwards.
Noah: Then what are the goals of the task force.
Yves: We will NOT get pushback if we do something specific.
Some discussion of the trade offs of features/generality versus speed
of shipping the spec.
DavidF: I hear one point of view that a bounded, scoped MTOM/MIFFY in
short time frame is preferable. Other view is that doing a general
approach will take more time.
Marc: I don't need something NOW. I do want something soon. I've been
telling people internally mid-year or a bit later.
DavidF: If we don't meet the March date we won't be at Rec until end
of 2004.
Noah: It's just a small spec. How can it possibly take another year?
Mark: We have other stuff to do in January.
DavidF: How important is it to have WSDL describe MIFFY/MTOM.
Various: Very important.
DavidF: I have a piece of work to do as chair to gather more
information on what is expected by the SVG/Core task force.
ACTION: Chair to talk to team about expectations re: MIFFY. ASAP.
DavidF: I think this meeting has been very successful. Work on
MIFFY/MTOM yesterday very productive. Also managed to make progress on
all the issues.
Thanks to BEA for hosting and for last nights dinner.
Adjourned.
Adjourn