Present 12, 9 AT&T, Mark Jones BEA Systems, Mark Nottingham (scribe4) Canon, Herve Ruellan IBM, David Fallside IBM, Noah Mendelsohn Microsoft Corporation, Martin Gudgin Oracle, Anish Karmarkar (scribe3) SAP AG, Gerd Hoelzing SAP AG, Volker Wiechers Sun Microsystems, Tony Graham (scribe2) W3C, Yves Lafon (scribe1) W3C, Carine Bournez Excused AT&T, Michah Lerner BEA Systems, David Orchard Canon, Jean-Jacques Moreau IBM, John Ibbotson Microsoft Corporation, Jeff Schlimmer Oracle, Jeff Mischkinsky Sun Microsystems, Marc Hadley Regrets Ericsson, Nilo Mitra Systinet (IDOOX), Jacek Kopecky SeeBeyond, Pete Wenzel Absent DaimlerChrysler R. & Tech, Andreas Riegg DaimlerChrysler R. & Tech, Mario Jeckle Fujitsu Limited, Masahiko Narita Fujitsu Limited, Kazunori Iwasa IONA Technologies, Eric Newcomer IONA Technologies, Seumas Soltysik Systinet (IDOOX), Miroslav Simek
Based on IRC log
[_Yves] binary xml workshop http://www.w3.org/2003/07/binary-xml-cfp.html ==Review Agenda== ==Action Items== ==Status Reports== [ScrYves] IETF process [ScrYves] Mark: IETF met last week in Geneva, no news yet, if nothing happen in the next month I'll contact them [ScrYves] reqs are waiting to be published, usage scenario will be sent for publication within a week ==PASWA & XQuery Data Model== [ScrYves] discussion started with http://lists.w3.org/Archives/Public/xml-dist-app/2003Jun/0004.html [ScrYves] poll: not many people know about XMLQuery data model [ScrYves] <Noah presents it> [ScrYves] same issues that came from Query and XPath/XSL, they gathered to have a unified view of the issue [ScrYves] in the model, they put the duality schema offers, character value AND a typed value [ScrYves] also a mapping from the infoset to the data model [ScrYves] document -> schema validation -> psvi [ScrYves] for soap we don't need schema validation [ScrYves] the string value is the canonical representation of the typed value (for string-value accessor) [ScrYves] we should see if it relates to paswa [ScrYves] Gudge: we are doing something simple, not sure moving to an XMLQuery datamodel based paswa won't add extra complication/time... [ScrYves] MarkN: base64 is one of the things we want to do. if we have only that it's simple, if we have a whole array of types, then it get more complicated [ScrYves] NM: schema aware optimisation of complex type is a bit what paswa does for base64 [ScrYves] paswa: all optimized elements were base64 binaries [ScrYves] for relays to work right, we have to say that it was optimizable, but also say that it is because it was in base64 [ScrYves] we may want to add hooks to optimize all nodes (imagine a large array of integers...) [ScrYves] NM: proposal we should note in mtom that for each soap msg there is a xquery datamodel [ScrYves] Gudge: people will assume there is a dependancy on the Xquery datamodel, and think they will require xQuery aware tools [ScrYves] NM: we should add as a note that it is _not_ require :) [ScrYves] DF: we need to analyse XQuery datamodel to ensure we won't have any edge cases [ScrYves] MJ: suppose you lose the type information when crossing an intermediary. You have the bits, but not the type [ScrYves] NM: we don't require validation [ScrYves] DF: we need to summarize a/ what we need to do, b/ what are the benefits [ScrYves] NM: a/ we would have to decide about intermediaries (optimize the first hop or the next hops?), should be carry types information ie, not only optimize base64? [ScrYves] Tony as mtom defines the serialization, and as Xquery have the same, not sure we need to go to XQuery [ScrYves] Volker: we should go there but use our own serialization [ScrYves] NM: my original plan was not to use Xquery serialization [ScrYves] Gudge: I would avoid that and be done as fast as possible. At best we may have it as on a parallel track and add this as an appendix. [ScrYves] Yves: if it saves us the trouble of fixing issues they already nailed, it is interesting [ScrYves] Noah: not sure how much of it we should do, we just need to know if we have the right hooks [ScrYves] (poll result: mostly pro, no-one strongly against if we can escape from a possible black hole) WG agreed to form a Task Force to pursue a XQuery Data Model based formulation (in parallel with other MTOM activities), so we can see what issues are unearthed and what are the complexities/benefits. Several WG members, including NoahM and @@, volunteered to participate in such a TF. [ScrYves] ---break--- [davidF] ---reconvene--- ==Presentation on 'Binary XML' etc== (new agenda item) [Gudge] MarcH blog: http://weblogs.java.net/pub/wlg/263 [ScrYves] MarkN presentation [ScrYves] (hint to MarkN it would be nice to have a URI) [ScrYves] reuse ASN.1 [ScrYves] ASN.1 encoding of the infoset [Tony] Submission to ISO: http://www.jtc1.org/ListOfFiles.asp?DocNumber=7116&SubComm=ISO/IECJTC1&Private=\False [ScrYves] MarkN there is a ASN.1 soap specific schema [ScrYves] Noah: fast schema encoding does not accomodate intermediaries [Tony] JavaOne FAST presentation, need to register to view PDF: http://servlet.java.sun.com/javaone/sf2003/conf/sessions/display-3752.en.jsp [ScrYves] Noah: is the intend to save bytes on the wire or save cpu cycles on the server? most probably cpu cycles for fast schema [ScrYves] DF: who will go to the W3C binary workshop? [ScrYves] (3 or 4 hands raised, + MarcH according to out of band information) ==AF Requirements Document== [ScrYves] new version at: http://lists.w3.org/Archives/Public/xml-dist-app/2003Jul/att-0050/2003-07-18-soap-attachment-feature.html [ScrYves] MarkJ: did some refactoring on the document [ScrYves] task force did a relevance check [ScrYves] work on use cases, already did some harvesting during last f2f, MarkN volunteering to do more [ScrYves] DF: the group will decide the items the TF will work on [ScrYves] <discussion about what are the requirements on, attachements or soap scalability or serialziation optimizations> [ScrYves] -> introduce in the preamble what we mean by attachments [mnot] binary underlying representation reification in type-aware optimisation [Gudge] one of my co-workers asked if MTOM stood for 'More Than Only MIME' [Gudge] or 'Many Things Only Minimalized" [ScrYves] ie: the scope of attachments [davidF] description of attachment to include "stuff not (easily) representable in XML" [davidF] .... as a starting point at least [ScrYves] NM: manifest, outside the scope of the requirements, but we won't preclude other TF to work on them [ScrYves] while the wg may decide to add them later [ScrYves] friendly amendment -> say that manifests are out of the scope of this document [ScrYves] informal poll: drop=2 outside the scope=1 -> drop [Tony] R9 [Tony] MN: 'should enumerate and describe its points of extensibility' [Tony] R9 to turn black. [Tony] R15 [Tony] R15: Delete stuff in square brackets. Turn black. [Tony] R24 [noah] Informal note: editor of requirement doc should consider tuning up the phrase "The >specification< should be conveniently describable.." It's not the spec that's describable. [Tony] R24: Delete. Add issue to issues list to develop WSDL for attachments [Tony] R17 [Tony] NM: Should describe support of and use with HTTP binding. Must describe relationship to current binding? Have proactive requirement to extend or superset current? [Tony] MG: WSDL WG putting in more explicit support for features and properties in WSDL 1.2. [Tony] R17: Keep. May revisit in future. [Tony] R32 [Tony] R32: Keep as is. Remove ednote. [Tony] R32: Remove 'and Binding' [Tony] R18 [Tony] R18: Defer until discussed R29. [Tony] --R27-- [noah] Proposal for R27 [noah] The specification should, to the extent possible, minimize the overhead involved in securing SOAP messages including content subject to optimized transmission. [Tony] R27: Adopt proposal. Make it black. [Tony] --R29-- working on wording: [davidF] A message with all its parts, however separated physically, must be representable as a single infoset. [davidF] A message with all its parts, however separated physically, must be describable as a single XML element in an XML schema. [Gudge] A message, however serialized must be representable as a single infoset [Gudge] A message, however serialized must be representable as a single SOAP message infoset [Gudge] A message, however serialized, must be representable as a single SOAP message infoset [Tony] R29: Replace text with last version of text (from Gudge). [Tony] --R18 revisited-- working on wording: [Gudge] The spec must support transmission of messages to SOAP nodes that do not support this specification. [Gudge] The spec must support tranmission of messages to down-level receivers that do not understand this specification [Gudge] The spec must support tranmission of messages to down-level receivers that do not understand the specification [Tony] R18: Replace with last version of text (from Gudge) [Tony] --3.2 Wire Format Requirements-- [Tony] --R1-- [mnot] It must be possible to select more than one portion of the message for optimisation [Gudge] The spec must define an infoset serialization that uses Multipart MIME [Tony] Proposal: Rename 3.2 to 'Serialization Requirements' [Tony] Proposal: Rename 3.2 to 'Infoset Serialization Requirements' [Tony] Proposal: Add new section 3.3 'Binding Requirements' [Tony] Proposal: Move Gudge's rephrase of R1 to new section 3.2. [Tony] Proposal: Add 'mnot' proposal as new requirement in Section 3.1. [noah] note....group agrees on preference for second form of 3.2 "Infoset Serialization Requirements" [Tony] Proposal: Move R17 to new section 3.3. [noah] Proposal for new requirement: [noah] The specification will include either an enhancement to the existing SOAP 1.2 HTTP binding or a new (but similar) binding. The new or extended binding will use the serialization to implement the Attachment Feature. [davidF] .... to be added to the new section 3.3 [davidF] proposal for 3.2, where it makes sense do s/The specification/The serialisation/ [noah] Proposal for R6, do s/Each part must be named by an absolute URI. /Within the serialization, each part must be named by an absolute URI. / [noah] Above is not being discussed at this time... see below [davidF] omnibus proposal .... [davidF] Add R33 to section 3.1: It must be possible to select more than one portion of the message for optimisation. [davidF] For section 3.2, R1: The spec must define at least one infoset serialization using Multipart MIME, and possibly additional serialisations. [davidF] Rename 3.2 to 'Infoset Serialization Requirements' [davidF] Add new section 3.3 'Binding Requirements' [davidF] Move R17 to new section 3.3. [davidF] Add R34 to section 3.3: The specification will include either an enhancement to the existing SOAP 1.2 HTTP binding or a new (but similar) binding. The new or extended binding will use the serialization to implement the Attachment Feature. [davidF] In section 3.2, where it makes sense do s/The specification/The serialisation/ [davidF] In R6 s/Each part must be named by an absolute URI. /Within the serialization, each part must be named by an absolute URI. / [davidF] end of proposal [Tony] Omnibus proposal accepted without objection. [davidF] ----break--- [davidF] ----reconvene---- [davidF] R2 .... [Tony] Proposal: Reword to 'The serialization must be able to carry arbitrary data, including non-XML data (e.g., binary data and XML fragments). [Tony] Proposal accepted. [Tony] R3 .... [Tony] Proposal: Ask ARTF to come up with preamble for section 3.2 with basic concepts [Tony] Proposal accepted. [Tony] Proposal to delete part (b) of R3 was accepted. [Tony] R4 .... [Tony] Proposal to keep it was accepted. [noah] Proposal for new requirement: [noah] The serialization should be designed to facilitate cooperation between inbound and outbound bindings at a SOAP intermediary, resulting in efficient relay of SOAP messages. [Tony] Proposal accepted to add new requirement as new R35 to appear in vicinity of R4/R5. [Tony] Proposal to keep R5 as is accepted without objection. [Tony] It was not noted previously, but proposal on R35 was accepted without objection. [Tony] R13 .... [Tony] Without objection, the WG will keep R13 as is. [Tony] R26 ... [Tony] Proposal (in 2 parts) .... [Tony] The specification should support streaming of serialization parts, i.e., chunked encoding. [Tony] Move second paragraph to use cases. [Tony] Two-part proposal accepted without objection. [Tony] R21 .... [mnot] proposal for definition of metadata in R21: (that is, information which is helpful to or required for the efficient operation of the binding, but is not necessarily available to the application) [Tony] Proposal: [Gudge] The s11n should provide for the existence and extension of metadata relating to the s11n [Gudge] . [Gudge] For example, the version number of the s11n [Gudge] s/provide/conveniently provide [davidF] proposal for R21: The s11n should conveniently provide for the existence and extension of metadata relating to the s11n, for example, the version number of the s11n. [davidF] proposal for R31: The s11n should conveniently provide for the existence and extension of metadata related to the s11n of individual parts. [Tony] Without objection, proposed rewrites of R21 and R31 were accepted. [Tony] R22 .... [RRSAgent] See http://www.w3.org/2003/07/24-xmlprotocol-irc#T15-33-34 [davidF] proposal that R22 be moved to sec. 3.1, and reworded as: Means must be provided in the infoset for optionally indicating the media type of binary element content. [Tony] Without objection, the proposal was accepted. [Tony] R30 ... [davidF] proposal: The specification must provide a facility for specifying length metadata information that is appropriate to meet likely buffering requirements of receivers. The use of this facility is optional. [davidF] proposal: The serialization must provide a facility for specifying length metadata that is appropriate to meet likely buffering requirements of receivers. The use of this facility is optional. [Tony] Without objection, the second version of the proposal was approved. [Tony] R6 .... for consideration at tomorrow's session [davidF] Proposal for R6: Within the serialization, each part must be named by an absolute URI. for consideration at tomorrow's session [Gudge] Possible new issue: should relative URIs in mtom:Representation header content be relative to the representation? [RRSAgent] I see 3 open action items: [RRSAgent] ACTION: XMLP members attending the XML Binary workshop to mention issues pertaining to SOAP [1] [RRSAgent] recorded in http://www.w3.org/2003/07/24-xmlprotocol-irc#T09-59-18 [RRSAgent] ACTION: MarkN to generate draft intro text and use cases from reqs doc discussions [2] [RRSAgent] recorded in http://www.w3.org/2003/07/24-xmlprotocol-irc#T10-09-03 [RRSAgent] ACTION: ARTF to generate the 3.2 preamble [3] [RRSAgent] recorded in http://www.w3.org/2003/07/24-xmlprotocol-irc#T14-44-05
Based on IRC log
[Yves] new attachment feature reqs doc available at http://www.w3.org/2000/xp/Group/3/02/24-soap-attachment-feature.html
==AF Requirements Document (cont.)==
[scribe] R6:
[davidF] Proposal for R6: Within the serialization, each part must be named by an absolute URI.
[RRSAgent] See http://www.w3.org/2003/07/25-xmlprotocol-irc#T07-01-48
[scribe] no objection to accepting the proposal for R6
[scribe] R7:
[scribe] http://www.w3.org/2000/xp/Group/3/02/24-soap-attachment-feature.html
[scribe] proposal to keep status quo for R7
[scribe] no objection to the proposal. R7 becomes 'black'
[scribe] R11:
[scribe] Gudge: not sure if I like this requirement. I may in fact want an order. for eg, same order as
the include elements
[scribe] Noah: suggestion - leave it as is, and rework this requirement through usecases
[scribe] Noah: OR include an ed note which says that we have dropped the requirement pending analysis of
the requirement
[scribe] Proposal: 1) delete the requirement, 2) ed note in place saying discussion about ordering is
taking place in usecase realm, 3) MarkN is tasked with hashing out this usecase
[scribe] no objection to accepting the proposal
[scribe] R12:
working on wording of proposal
[Gudge] The serialization part(s) carrying the document element must be easily locatable/identifiable
[Gudge] The serialization part(s) carrying the start of the document element must be easily locatable/identifiable
[Gudge] The serialization part carrying the start of the document element must be easily locatable/identifiable
[Gudge] The serialization part carrying the start of the primary document element must be easily locatable/identifiable
[Gudge] The serialization part carrying the start of the primary envelope document element must be easily locatable/identifiable
[scribe] (no objection to acceptin Gudge's last proposal - The serialization part carrying the start of the
primary envelope document element must be easily locatable/identifiable)
[scribe] -- discussion of new requirements sent by MarkN --
new requirements described at:
[herve] http://lists.w3.org/Archives/Public/xml-dist-app/2003Jul/0052.html
[mnot] http://www.w3.org/mid/022b01c34fc5$313b5730$481e11ac@mnotlaptop[scribe] proposal - include (1) as usecase
[scribe] no objection to accepting the proposal
[scribe] proposal - include (2) as usecase
[scribe] no objection to accepting the proposal
[scribe] proposal - include (3) as usecase
[scribe] no objection to accepting the proposal
[scribe] noah: proposal - drop it, add ed note that we are analysing this requirement, waiting usecase analysis
[scribe] proposal - do not include (4) as R30 covers this
[scribe] no objection to accepting the proposal
[scribe] proposal - not consider (5) in light of R18
[scribe] no objection to accepting the proposal
[scribe] -- end of discussion of MarkN's email (requirements) --
[scribe] DF: what do we think we need to do before we can publish the 1st draft of the requirements doc?
[davidF] (1st draft = W3C Working Draft)
[scribe] <wg thinks that a analysis of the usecases and editorial pass + title/introduction resolution)
[scribe] DF: we could have an action to proposal preamble/intro text. We have one more telecon before the quite period
[scribe] MarkN: concern about publishing this before usecase analysis
[scribe] DF: we will wait till sept. for publishing the 1st WD of the req. doc
[scribe] The WG thinks that the following needs to happen before the requirements doc can be published as the 1st WG:
[scribe] 1) editorial pass
[scribe] 2) title resolution
[scribe] 3) preamble text
[scribe] 4) preamble text for secton 3.2 (already an AI)
[scribe] 5) analysis of the usecases
==Attachment Issues==
[scribe] Noah: new issue - when should we (or should we) establish base URIs for PASWA contained content
[scribe] Gudge: I wonder whether it applies generally or only to Representation header?
[scribe] <WG agrees that this is an issue>
[scribe] no objection to adding this as a new issue
[scribe] -- break --
[_Yves] new version of http://www.w3.org/2000/xp/Group/3/02/24-soap-attachment-feature.html in place
[davidF] -- end break --
[noah] http://www.w3.org/2000/xp/Group/xmlp-issues.html#x431
[scribe] Issue 431:
[scribe] DF: do we think we have a resolution for this issue? is there a common understanding of the issue?
[scribe] Gudge: we don't want to mandate what the intermediaries must always do, but perhaps we may define
a mechanism where the sender can specify (optionally) what the intermediary must do.
[scribe] Noah: replace this with an issue which says - consider all aspects of PASWA and intermediaries
[Gudge] Open questions about intermediary behaviour:
[Gudge] 1. Can intermediaries optimize a different set of elements to the set it received
[Gudge] 2. Can intermediaries change the serialization order of optimized data
[Gudge] 3. Can intermediaries change the 'chunk' size of optimized data
[scribe] Gudge: we just need to define a set of properties that are populated by the sender and receiver and
if the next hop uses the same binding then the properties can be transfered to the next link
[scribe] DF: the secondary question for this issue is - what is the impact to our document(s) to fill in
these properties. Do we have these properties listed out?
[scribe] Gudge: there is only one properties described (receiver side property for optimized elements).
[scribe] Noah: there properties that are independent of the binding. There is a set of information that is
specific to the binding.
[scribe] Noah: binding specific information/properties also has to be specified (and intermediary beharior)
[scribe] Noah: we need a place holder for binding specific things
[scribe] Gudge: I am not sure whether binding specific information is important.
[scribe] Noah: it is helpful to include a Note in the spec to say that two bindings on two links of an intermediary
(or two instances of the same binding) can conspire to share properties/information
[scribe] MarkJ: if you wanted to have a broader conspiracy then do we have a mechanism?
[scribe] Gudge: yes, soap headers.
[scribe] Noah: there a MTOM properties which are not in the env. They do not have a life beyond the hop. There may
be a need to make such information available outside the hop. In this case, the info has to be made available in a
SOAP header
[scribe] Noah: one problem is the binding cannot change soap headers
[scribe] Gudge: binding and soap processor is indistinguishable from outside
[scribe] DF: i believe there is an agreement to work on two things - list of properties for binding and possibly
information related to "binding level optimization informantion".
[scribe] DF: we have considered to the extend we can issues 431 and 436. We should keep them open and move on to
issue 432
[scribe] Issue 432:
[scribe] proposal from Jacek - http://lists.w3.org/Archives/Public/xml-dist-app/2003Jul/0036.html
[scribe] <discussion about whether the 'MUST' in Jacek's proposal is correct>
[scribe] Gudge: the binding specification could specify what it means to send a particular
element in an optimized way (eg: as a separate MIME part)
[scribe] MarkJ: concern about relying on the binding to do the optimization when decisions
have been made (about optimization) at a level higher
[scribe] MarkN: we need to make a decision whether we are happy with restricting ourselves
to base64
[scribe] Noah: I think we are ok with that right now, when we look at XQuery.
[scribe] DF: looks like we have a proposal - we assign an action to someone to generate text
and resolution of 432 which specifies that these are base64 ??
[Gudge] s/these/optimized elements
[Gudge] s/are base64/have base64 content
[scribe] DF: ... and we generate a new issue whether base64 is the only type that we consider
[Gudge] Proposal: assign an action to someone to generate text and resolution of 432 which
specifies that the OptimizedElement property contains elements whose content is known to be
base64 characters
[Gudge] and generate a new issue concerning whether base64 characters is the only type we optimize
[davidF] </proposal>
[scribe] no objection to accepting the proposal
[davidF] note to Noah: see Jacek's email at
http://lists.w3.org/Archives/Public/xml-dist-app/2003Jul/0036.html for hints on which section(s) to edit
[scribe] Gudge: proposal - we have an action which will deal with issue 435
[Gudge] specifically, my action to provide a proposal for extra properties needed for
communicating optimizations across intermediaries will address 435
[scribe] -- lunch break --
==Attachment Documents==
[Gudge] jacek's proposal: http://lists.w3.org/Archives/Public/xml-dist-app/2003Jul/0013.html
[mnot_scribe] * discussion of Jacek's proposal for media types
[mnot_scribe] PROPOSAL: accept 5.1, if media type is reflected in the infoset, it SHOULD use this mechanism;
[_Yves] whiteboard is at http://www.w3.org/2000/xp/Group/3/07/whiteboard.jpg
[mnot_scribe] PROPOSAL: accept 5.1; if you want to assign a media type to the base64
content of an element, you SHOULD use this mechanism.
[mnot_scribe] proposal accepted with no objection.
[Gudge] <xs:complexType name='base64Binary' >
[Gudge] <xs:simpleContent>
[Gudge] <xs:extension base='xs:base64Binary' >
[Gudge] <xs:attribute ref='tns:media-type' use='optional' />
[Gudge] </xs:extension>
[Gudge] </xs:simpleContent>
[Gudge] </xs:complexType>
[Gudge] *
[Gudge] <xs:complexType name='BinaryWithoutMediaType' >
[Gudge] <xs:simpleContent>
[Gudge] <xs:restriction base='tns:base64Binary' >
[Gudge] <xs:attribute ref='tns:media-type' use='prohibited' />
[Gudge] </xs:restriction>
[Gudge] </xs:simpleContent>
[Gudge] </xs:complexType>
[Gudge] *
[Gudge] <xs:complexType name='BinaryWithMediaType' >
[Gudge] <xs:simpleContent>
[Gudge] <xs:restriction base='tns:base64Binary' >
[Gudge] <xs:attribute ref='tns:media-type' use='required' />
[Gudge] </xs:restriction>
[Gudge] </xs:simpleContent>
[Gudge] </xs:complexType>
[davidF] (note on resolution of previous proposal - disposition of text in document is TBD)
[Gudge] s/base64Binary/BInary
[Gudge] s/xs:BInary/xs:base64Binary
[mnot_scribe] PROPOSAL: accept 5.2 w/ Gudge's types
[mnot_scribe] proposal accepted with no objection.
[davidF] (Gudge's types = the 3 complexType defns above)
[noah] Proposed ednote on 5.3
working on proposal wording ...
[noah] The XML Protocols Workgroup encourages the WSDL and/or XML Schema workgroups to
consider mechanisms that might be used to describe or validate media typed content.
We believe that the mechanisms of 5.2 are ammendable to such description, and we solicit
feedback on this aspect of our design.
[noah] The XML Protocols Workgroup encourages the WSDL and/or XML Schema workgroups to
consider mechanisms that might be used to describe or validate media typed content.
We believe that the mechanisms of 5.2 are ammenable to such description, and we solicit
feedback on this aspect of our design.
[mnot_scribe] proposal above accepted without objection.
[davidF] <xs:pattern value="(text|application|image|audio|video|model|multipart|message|x-[-.a-z0-9]+)/
[a-z0-9][-.+a-z0-9]+(;\s?.+=.+)*" />
[mnot_scribe] PROPOSAL: accept the attribute definition with the modification that the
restriction does not enumerate the mime media types. (Adjust regex to syntactically
validate the media type).
[davidF] <xs:pattern value="([a-z0-9][-.+a-z0-9]+(;\s?.+=.+)/[a-z0-9][-.+a-z0-9]+(;\s?.+=.+)" />
[davidF] (attribute defn referred to is in http://lists.w3.org/Archives/Public/xml-dist-app/2003Jul/0013.html)
[Gudge] <xs:attribute name='media-type' form='qualified' >
[Gudge] <xs:simpleType>
[Gudge] <xs:restriction base='tns:mediaType' >
[Gudge] <xs:enumeration value='image/jpeg' />
[Gudge] <xs:enumeration value='image/gif' />
[Gudge] </xs:restriction>
[Gudge] </xs:simpleType>
[Gudge] </xs:attribute>
[davidF] (gudge has typed in an example to illustrate a question wrt usage of schema defn)
[noah] Another proposal: The XML Protocols Workgroup encourages the WSDL and/or XML
Schema workgroups to consider mechanisms that might be used to describe or validate
media typed content. We believe that the mechanisms of 5.2 are ammenable to such
description, but we note that there are some challenges regarding the ability to
create schemas that accept only particular media types, such as image/jpeg. We
solicit feedback on this aspect of our design.
[davidF] OMNIBUS PROPOSAL:
[davidF] 1. accept the attribute definition with the modification that the restriction
does not enumerate the mime media types. (Adjust regex to syntactically validate the
media type).
[davidF] 2. Ed Note. The XML Protocols Workgroup encourages the WSDL and/or XML Schema workgroups
to consider mechanisms that might be used to describe or validate media typed content.
We believe that the mechanisms of 5.2 are ammenable to such description, but we note that
there are some challenges regarding the ability to create schemas that accept only
particular media types, such as image/jpeg. We solicit feedback on this aspect of our
design.
[davidF] {(2) modifies previous accepted proposal for 5.3}
[davidF] END OMNIBUS PROPOSAL
[mnot_scribe] omnibus proposal is accepted without objection.
[davidF] --break --
[Gudge] Proposal from MarcH: http://lists.w3.org/Archives/Public/xml-dist-app/2003Jul/0032.html
[davidF] --end break--
[Gudge] Proposal from MarcH: http://lists.w3.org/Archives/Public/xml-dist-app/2003Jul/0032.html
[davidF] http://lists.w3.org/Archives/Public/xml-dist-app/2003Jul/0032.html
[davidF] discussion of some ideas created informally by MN and NM regarding implications of media type and its relation to optimisation
AI assigned to MarkN to start a thread on "Options for Flagging MTOM Processing" in dist-app to discuss the relative
merits, pros, cons of each option.
[RRSAgent] I see 9 open action items:
[RRSAgent] ACTION: markJ to generate preamble text before next telecon [1]
[RRSAgent] recorded in http://www.w3.org/2003/07/25-xmlprotocol-irc#T08-00-29
[RRSAgent] ACTION: DF to setup ARTF telcon before next week's WG telcon [2]
[RRSAgent] recorded in http://www.w3.org/2003/07/25-xmlprotocol-irc#T08-01-37
[RRSAgent] ACTION: Noah - to send an email discribing the issue (about base URI) to distapp [3]
[RRSAgent] recorded in http://www.w3.org/2003/07/25-xmlprotocol-irc#T08-10-32
[RRSAgent] ACTION: Gudge to provide proposal for extra properties ( like the current OptimizationCandidates property ) needed for
communicating optimization information across intermediaries. Due 2003-09-01 [4]
[RRSAgent] recorded in http://www.w3.org/2003/07/25-xmlprotocol-irc#T09-36-31
[RRSAgent] ACTION: Noah to provide proposal for binding level intermediary optimizations. Due 2003-09-01. [5]
[RRSAgent] recorded in http://www.w3.org/2003/07/25-xmlprotocol-irc#T09-41-22
[RRSAgent] ACTION: Noah to generate new proposal for 432 ( as above ) [6]
[RRSAgent] recorded in http://www.w3.org/2003/07/25-xmlprotocol-irc#T10-23-38
[RRSAgent] ACTION: markN to send an email to disapp about new issue concerning whether base64 characters is the only type we optimize [7]
[RRSAgent] recorded in http://www.w3.org/2003/07/25-xmlprotocol-irc#T10-28-03
[RRSAgent] ACTION: mnot to check and adjust regex as appropriate [8]
[RRSAgent] recorded in http://www.w3.org/2003/07/25-xmlprotocol-irc#T13-36-39
[RRSAgent] ACTION: generate options for flagging processing in the binding (w/ pros+and cons) to mnot by next telcon [9]
[RRSAgent] recorded in http://www.w3.org/2003/07/25-xmlprotocol-irc#T14-58-12