See also: IRC log
<jkaputin> Roland Merrick is actually John Kaputin (Apache Woden/IBM) standing in for Arthur Ryman
<scribe> scribe: tonyr
minutes approved without dissent
Review of Action items [.1].
[Interop]
? 2006-11-30: [interop] John Kaputin to create a test case
with "required=false".
? 2006-12-14: [interop] Jonathan to fix transferCodings -
add control group
DONE [.3] 2007-01-18: [interop] Jonathan to factor multipart out of
MessageTest-2G
[WG]
? 2006-09-21: Jonathan to check periodically that SPARQL has
added schemaLocation.
? 2006-12-14: plh to come up with a more detailed proposal for
CR112 if possible
? 2007-01-04: Paul to report back on which test cases in the
WSDL test suite fail the basic patterns, with
suggestions on how to address the issues.
DONE [.4] 2007-01-04: Jonathan to analyze CR117 further.
? 2007-01-11: Jean-Jacques to provide more analysis on how
difficult it would be deal with a Policy that
only contains an MTOM policy assertion
Current Editorial Action Items
Note: Editorial AIs associated with LC issues recorded at [.2].
[.1] http://www.w3.org/2002/ws/desc/#actions
[.2] http://www.w3.org/2002/ws/desc/5/cr-issues/actions_owner.html
[.3] http://lists.w3.org/Archives/Public/www-ws-desc/2007Jan/0159.html
[.4] http://lists.w3.org/Archives/Public/www-ws-desc/2007Jan/0162.html
WS-Policy responses have been accepted and applied to their spec; Charlton tracking
<alewis> i haven't seen anything, as i recall.
<Zakim> asir, you wanted to ask a question?
<alewis> grr. what happened?
draft of charter for the XML-P group, including MTOM
Jonathan: suggest we forward Jean-Jacques' comments on the XML-P charter to the CG and the authors of the charter
JJM: pleased that the charter is happening, but would be happier if it were more detailed
Jonathan: any specifics?
... will forward JJM's comments, but want to know if the WG has
any other specific recommendations to the authors
<asir> Here is the link http://www.w3.org/Submission/2006/SUBM-WS-MTOMPolicy-20061101/
<pauld> also had a challenge when looking at the charter
<charlton> thanks asir
<pauld> http://www.w3.org/2007/01/XML-Protocol-Charter.html
jjm: could not reach the submission by clicking on the link in the charter - permissions issue
<asir> am wondering why such specific comments cannot be handled through Canon AC representative
<scribe> ACTION: Jonathan to forward comments to the author of the MTOM charter [recorded in http://www.w3.org/2007/01/25-ws-desc-minutes.html#action01]
<scribe> ACTION: Jean-Jacques to develop more concrete suggestions for expansion of the charter for the XML-P group [recorded in http://www.w3.org/2007/01/25-ws-desc-minutes.html#action02]
<asir> thank you for the clarification
waiting on input from Philippe - skipping
Jonathan: we agreed that the
status quo is clear
... perhaps current model is unclear, and we could remove those
items that are not referred to by any WSDL component
Roberto: not sure that the status quo says what you said it does
JohnK: I agree - not certain that the spec says clearly what is included
Roberto: argument detailed in
e-mail is that we should only include in the component model
those items which are referenceable
... those elements which are inported by things which are
imported cannot be referenced unless also directly imported;
only those items which are directly imported should be
included
JohnK: agreed - only those items
which can be referenced should be included in the component
model
... Arthur had some concerns about referencability. Once we
reach the component model we lose the understanding of which
elements are referenceable because referenceability is a
property of the document
Roberto: not sure that I agree. Yes, referenceability is a feature of the document, but if we follow the procedure I outline we will get a suitable set of components
JohnK: inclined to agree.
Including everything clutters the component model with
components which are not used because they were not able to be
referenced
... prefer Roberto's proposal
Jonathan: like Roberto's proposal, too - it reinforces the idea of import; produces a nicer "mental model"
JohnK: we haven't covered the
likely use cases - Arthur could address that if he were
here
... we may need to revisit this if Arthur has additional use
cases
Jonathan: are we clear on the wording we require in the spec?
<scribe> ACTION: Roberto to suggest more concrete wording for the spec for CR145 [recorded in http://www.w3.org/2007/01/25-ws-desc-minutes.html#action03]
<Marsh> Look at sections 3.1.3 and the Desc Comp section 2.1.1
JohnK: section 3.1.3 and Description Component section in Part 1
Jonathan
Jonathan: this is about encoding
the data included in a URI - what rules we should follow in
determining which parts of the data are URL-encoded?
... we had two proposals:
... 1. augment the template syntax to indicate which parameters
should be / should not be encoded
... 2. always encode all parameters, ensuring everything is
always reversible
... in this case we'd ensure that all parameters must be
separated by an unescaped character not in the set of unescaped
characters
Jacek: you are talking about reconstructing the query from the URL - has this ever been an objective of the spec?
Jonathan: no, but our implementations have been requiring this ability
Youenn: yes, it makes sense to be able to reconstruct
Roberto: I like the idea of the
different templating syntax. That would be a good solution,
using two different serialisation "modes"
... on the other hand, I don't like the other proposal - to
insist on unique deserialisation
Youenn: I think it's just a warning, not an error
Jonathan: the raw vs encoded proposal doesn't solve the real problem, which is the unique deserialisation
Jacek: I don't like the idea of
adding a new feature at this time, which would require
returning to LC again.
... perhaps we should add an XML simple type which disallows
the set of characters which cause problems
Jonathan: can we create a simple type to do this? Right now we'd need a BNF
Youenn: the writer of the binding may not be the writer of the interface
Jacek: don't we already have this
problem?
... wouldn't mind that all that much - already constrained
Jonathan: Jacek's proposal is
that we add descriptive text about problems in some operations
due to ambiguity from including certain characters in
parameters, and provide a simple type to avoid these
ambiguities
... This would not avoid the problem of reversability - will
not be able to reconstruct the original query
Youenn: the server may not be able to understand the message
Jacek: The server will break? I can't see the problem here
Jonathan: unless you constrain the data in the URL, the server may be "confused"
Jacek: we have the problem already in other places - a "first name" field that could be "any string" could be sent a 5Mb string, which could cause problems with most servers
Youenn: perhaps we could insist that uncited parameters which go into the query string be encoded; cited parameters would not be encoded
Jonathan: how does that solve the problem?
Jacek: the uncited parameters would not be able to mess up the cited parameters
Jonathan: sounds like my second
proposal is DOA (mandatory encoding + ban ambiguity)
... could adopt my first proposal, or Youenn's proposal
<JacekK> chad, question: CR117
<JacekK> chad, question?
<JacekK> chad, options?
<alewis> vote: 4, 3, 5, 2
<JacekK> vote: 4, 2, 0
vote: 4, 0, 5, 2, 3
<charlton> vote: 4, 5, 2, 3
<youenn> vote: 5, 1, 2, 3, 4
<Allen1> vote: 4, 0
<Roberto> vote: 1, 4, 0, 5, 3, 2
<gpilz> vote: 4, 5, 3, 2
<monica> 1,4,no others
<Jonathan> vote: 3, 5, 2
<JacekK> vote: monica: 1, 4
<jjm> vote: 5, 1, 2, 3, 4
<JacekK> chad, count
<chad> Question: CR117
<chad> Option 0: status quo (0)
<chad> Option 1: jonathat's 1st - new syntax for controlling whether or not to encode (2)
<chad> Option 2: youenn - cited parameters raw, uncited encoded (0)
<chad> Option 3: jonathat's 2nd - everything encoded, ambiguity forbidden (1)
<chad> Option 4: jacek's - all is raw, we warn people, give them guidance and maybe a restrictive simple type (6)
<chad> Option 5: everything encoded (2)
<chad> 11 voters: alewis (4,3,5,2),Allen1 (4,0),charlton (4,5,2,3),gpilz (4,5,3,2),JacekK (4,2,0),jjm (5,1,2,3,4),Jonathan (3,5,2),monica (1,4),Roberto (1,4,0,5,3,2),TonyR (4,0,5,2,3),youenn (5,1,2,3,4)
<chad> Round 1: Count of first place rankings.
<chad> Candidate 4 is elected.
<chad> Winner is option 4 - jacek's - all is raw, we warn people, give them guidance and maybe a restrictive simple type
Straw poll indicates a strong preference for Jacek's proposal
<monica> need to play lotto
<monica> $240 millon in oregon
youenn: dislike this proposal. Might be better to support the use cases we know; don't want to block future use cases
Jacek: can the use cases that
this proposal blocks be addressed in the application?
... application can be built to use encoding where needed
... adding path segments is a use case which would be blocked
by encoding everything
<JacekK> chad, clean
Jacek: using Youenn's proposal would still allow us to warn people of the consequences
<JacekK> chad, reset
<chad> new poll
<JacekK> chad, question: CR117
<Roberto> I prefer option 1, having authors explicitly choose between raw and encoded, over option 2
<asir> Are there any concrete proposals written down for any of these options?
Tony: concerned about security issues with RAW parameters
Jacek: have the same issues
without WSDL - a user can enter a URL without using the WSDL,
so there's no security hole (that wasn't already present)
... might avoid bugs / undocumented features by encoding, but
nothing more
Youenn: would prefer to offer a choice of RAW/encoded
Jacek: we have a default - the status quo is that we leave everything RAW
Youenn: not sure that the default was thought through
Jacek: we are in CR - reluctant
to change things at this point
... we can provide advice, and offer a simple type to avoid
issues
Youenn: but there are values which won't be valid according to the simple type - some book titles won't be accepted
Jacek: if we want to put things into a URI, you have to encode them
Youenn: cannot automate the reconstruction of the query from the URL
Jacek: wonder what the web people would say about this - if we are constructing a URI, we are addressing a resource, and the resource should "know what to do"
Jonathan: there are fiddly bits in the HTTP binding. if we don't do any encoding, then there are more restrictions on the data we can use
<Roberto> if there are two classes of users with two different use cases, it makes sense to have two template syntaxes, i.e. option 1
Jonathan: guess we'll have to return this one to the mailing list. Please describe the positions clearly
<Jonathan> Thanks Tony!