16:04:22 <RRSAgent> RRSAgent has joined #ws-desc
16:04:22 <RRSAgent> logging to http://www.w3.org/2005/09/26-ws-desc-irc
16:04:28 <Zakim> +Hugo
16:06:46 <TomJ> TomJ has joined #ws-desc
16:07:01 <TonyR> TonyR has joined #ws-desc
16:07:04 <Zakim> +Jacek
16:07:38 <alewis> alewis has changed the topic to: Web Services Description Working Group Face to Face, Palo Alto, 617 761 6200 code 97323
16:10:27 <TomJ> we are here
16:11:54 <youenn> youenn has joined #ws-desc
16:24:30 <anish> anish has joined #ws-desc
16:24:54 <youenn> youenn has joined #ws-desc
16:26:38 <anish> Scribe: anish
16:26:42 <anish> Agenda: http://lists.w3.org/Archives/Public/www-ws-desc/2005Sep/0040
16:26:55 <anish> Chair: Jonathan Marsh
16:28:14 <Zakim> +Canon
16:28:31 <anish> Topic: Action Item Review
16:28:31 <youenn> Zakim, canon holds youenn
16:28:31 <Zakim> +youenn; got it
16:29:50 <anish> Topic: Future meetings
16:29:58 <uyalcina> uyalcina has joined #ws-desc
16:30:01 <anish> JM: few people expressed interest
16:30:08 <bijan> bijan has joined #ws-desc
16:30:17 <anish> Roberto: Sun may be able to do it
16:31:14 <pauld> pauld has joined #ws-desc
16:31:20 <Marsh> Marsh has joined #ws-desc
16:32:06 <anish> <more discussion on Jan F2F>
16:32:15 <anish> JM: east coast would be great
16:32:36 <anish> JM: candidates -- week of 16th or 21st
16:32:54 <anish> s/21st/23rd/
16:35:10 <anish> JM: we should think about our agenda for the jan f2f, perhaps a interop bakeoff
16:36:49 <pauld> IBM / Axis Wave / Particle duality discussion
16:37:45 <kliu> kliu has joined #ws-desc
16:38:24 <anish> JM: another option is to not have a full WG meeting, but go thru the test cases
16:38:35 <anish> Sanjiva: distributed meeting may make sense in that case
16:38:42 <Arthur> Arthur has joined #ws-desc
16:38:50 <anish> JM: we may be able to go to CR before Tokyo F2F
16:38:57 <Roberto> Roberto has joined #ws-desc
16:41:00 <anish> no decision on jan f2f. Few options. Decision will be made later
16:41:32 <anish> Jonathan: i18n is going to be 3 weeks late on sending comments
16:42:17 <anish> Topic: issue LC315
16:42:29 <youenn> youenn has joined #ws-desc
16:43:26 <anish> proposal from Hugo: http://lists.w3.org/Archives/Public/www-ws-desc/2005Sep/0037.html
16:45:46 <anish> Hugo explains his proposal
16:47:02 <hugo> <whttp:header name="foo" type="bar:foobar" />
16:47:54 <hugo> <whttp:header element="bar:foo" /> <- proposal 2
16:47:55 <RebeccaB> RebeccaB has joined #ws-desc
16:49:37 <RebeccaB> RRSAgent, where am I
16:49:37 <RRSAgent> I'm logging. I don't understand 'where am I', RebeccaB.  Try /msg RRSAgent help
16:49:57 <anish> Tom: like proposal 1, but not restricted to simple types
16:50:20 <jjm> jjm has joined #ws-desc
16:52:04 <hugo> "{type}, REQUIRED." should have: "This type MUST be a simple type."
16:52:43 <TomJ> using element in this context is wacky
16:53:38 <anish> anish: concerns about proposal 1 -- reminds of rpc/encoded
16:54:27 <anish> tom: there is some text (from proposal 2) that needs to be included in proposal 1
16:57:55 <anish> tom: need to make it clear that we are serialization the value and not angle brackets
16:58:08 <anish> JM: proposal 1 with 2 amendments --
16:58:13 <TomJ> If we can use the words lexical or string representation to make clear there are no angle brackets in the value
16:58:40 <anish> 1) make it clear that the types are restricted to simple types
16:58:50 <Marsh> http://lists.w3.org/Archives/Public/www-ws-desc/2005Sep/0017.html
16:59:06 <anish> 2) If we can use the words lexical or string representation to make clear there are no angle brackets in the value
17:00:31 <anish> Jacek's concern -- http://lists.w3.org/Archives/Public/www-ws-desc/2005Sep/0017.html
17:04:06 <anish> Jonathan: we could write the schema to restrict the length of name
17:05:36 <anish> Jacek: we should say that the values (at runtime) described by the type must not contain values that are disallowed
17:06:33 <anish> Tom: to reiterate the proposal -- we include the limitation on the length of the header, for values we reference the relevant RFCs
17:06:56 <anish> arthur: in addition our schemas should enforce that (for the name of the header)
17:07:39 <Marsh> ack hugo
17:07:39 <Zakim> hugo, you wanted to ask about the ASCII restriction
17:07:52 <anish> hugo: don't dislike tom's proposal too much
17:08:13 <Arthur> in general, our spec should refer to definitions from other specs instead of copying the definitions
17:08:27 <Arthur> our schema should enforce as much as it can
17:08:43 <charlton> charlton has joined #ws-desc
17:09:03 <hugo> [[
17:09:04 <hugo>    The TEXT rule is only used for descriptive field contents and values
17:09:04 <hugo>    that are not intended to be interpreted by the message parser. Words
17:09:04 <hugo>    of *TEXT MAY contain characters from character sets other than ISO-
17:09:04 <hugo>    8859-1 [22] only when encoded according to the rules of RFC 2047
17:09:07 <hugo>    [14].
17:09:09 <hugo>        TEXT           = <any OCTET except CTLs,
17:09:12 <hugo>                         but including LWS>
17:09:12 <anish> hugo: tom's proposal does solve the problems and we should remove any mention of UTF8
17:09:14 <hugo> ]]
17:10:11 <hugo> [[
17:10:11 <hugo>        message-header = field-name ":" [ field-value ]
17:10:11 <hugo>        field-name     = token
17:10:11 <hugo>        field-value    = *( field-content | LWS )
17:10:11 <hugo>        field-content  = <the OCTETs making up the field-value
17:10:14 <hugo>                         and consisting of either *TEXT or combinations
17:10:16 <hugo>                         of token, separators, and quoted-string>
17:10:19 <hugo> ]]
17:11:51 <anish> JM: we have 2 amendments for Hugo's proposal 1 + include the desc of how to make a HTTP name (Jacek's email) and we put that in our schema + for the value of the header we reference the HTTP specs and say that this has to be followed
17:11:59 <anish> s/JM:/Tom:/
17:12:36 <anish> JM: plus we need to remove UTF8
17:13:13 <anish> JM: we have a new property called 'type', should we call it 'simpleType'
17:13:46 <anish> arthur: we should call it 'type definition' rather than 'simple type'
17:14:28 <anish> JM: any objections to the proposal with the 4 (or 4.5 amendments)?
17:15:04 <anish> arthur: if we have qname references to types what happens if it is a buildin type?
17:15:23 <anish> ... it has to be a definition of a schema type definition component
17:15:46 <anish> glen: then every builtin type has a type component definition
17:16:08 <anish> arthur: worried about how things get parsed
17:16:28 <anish> ... we don't have an import for builtin types
17:16:37 <anish> umit: i think it is irrelevant
17:16:46 <anish> ... i don't think we should go there.
17:17:12 <anish> JM: addition of a sentence regd this would solve the problem
17:18:04 <anish> JM: arthur can you look at this and raise an issue if this is a problem
17:18:35 <anish> ACTION: Arthur to figure out how to treat builtin schema types
17:20:19 <anish> roberto: the status right now is you create a lexical representation, then you encode it as utf8 and then check whether there is a problem?
17:20:47 <anish> amy: the rfc says utf 8 (rfc 2822)
17:21:16 <anish> ... nothing to gain by transforming to utf8
17:21:52 <anish> amy: the http spec says iso-8859-1 not utf8
17:22:13 <anish> JM: we agree to remove the words: "in utf8" from hugo's proposal 1
17:22:30 <anish> JM: any objections to adopting proposal 1 with all the amendments
17:22:34 <anish> <no objections>
17:22:41 <anish> Issue LC315 is closed
17:23:03 <anish> Topic: issue 321
17:23:21 <Marsh> http://lists.w3.org/Archives/Public/www-ws-desc/2005Sep/0011.html
17:24:09 <anish> tom: like it
17:24:12 <anish> sanjiva: +1
17:24:43 <anish> JM: any objections to accepting Asir's proposal?
17:24:45 <anish> no objections
17:25:06 <anish> RESOLUTION: 315 closed with Asir's proposal
17:25:37 <anish> s/315/321/
17:25:54 <anish> RESOLUTION: 315 closed with Hugo's proposal 1 with various amendments
17:26:04 <anish> Topic: LC326
17:27:58 <anish> JM: do we have a close enumeration or extensible
17:30:36 <TomJ> wouldnt is be ok to leave it alone and allow other values?
17:30:39 <TomJ> s/is/it/
17:30:42 <anish> JM: any objection to closing issue 326 with Hugo's proposal?
17:30:57 <anish> no objection
17:31:08 <anish> RESOLUTION: LC326 resolved with Hugo's proposal
17:31:34 <anish> 20 minute break
17:31:38 <anish> -------------------------------
17:32:30 <Zakim> -Jacek
17:52:00 <jjm> jjm has joined #ws-desc
17:53:09 <Zakim> -Canon
17:53:46 <Zakim> +Canon
17:55:52 <anish> back
17:56:00 <anish> back from the break
17:56:55 <anish> Topic: Issue LC319
17:56:58 <Zakim> +Jacek
17:57:14 <anish> proposal from hugo -- http://lists.w3.org/Archives/Public/www-ws-desc/2005Sep/0012.html
17:58:53 <anish> JM: any objection to the proposal?
17:58:56 <anish> no objection
17:59:09 <anish> RESOLUTION: LC319 resolved with hugo's proposal
17:59:39 <dorchard> dorchard has joined #ws-desc
18:00:40 <anish> Topic: Issue LC 339
18:02:07 <anish> Glen: when u see a soap header decl, do i have to send one, or two etc. If you see the Qname of the header you know the spec. If the spec says that the header is to be sent only between 3pm and 5pm then you know what to do. OR have a minOccurs/maxOccurs
18:02:35 <anish> sanjiva: this is a slippery slope to having a 'message' structure
18:03:26 <Marsh> ack hugo
18:03:26 <Zakim> hugo, you wanted to propose not to change anything
18:03:28 <anish> q+
18:04:41 <anish> hugo: this is a nice feature to have but we want to be done
18:04:50 <anish> ... so we don't change it
18:05:06 <hugo> http://www.w3.org/TR/2005/WD-wsdl20-adjuncts-20050803/#soap-defaults
18:05:18 <hugo> "If the {soap headers} property as defined in section 5.10 Declaring SOAP Header Blocks exists and is not empty in a Binding Message Reference or Binding Fault component, element information item conforming to the element declaration of a SOAP Header Block component's {element} property, in the {soap headers} property, MUST be turned into a SOAP header block for the corresponding message."
18:06:41 <Marsh> ack anish
18:08:36 <anish> anish: why don't we add what we already have for wsoap:module
18:09:45 <anish> JM: can we say if you see wsoap:header then it is exactly 1 (cardinality
18:09:48 <anish> ... )
18:15:01 <anish> <more discussion on cardinality of headers>
18:16:10 <anish> davidO: only interested in 0 or 1. not interested in > 1
18:17:33 <anish> glen: change the text to say zero or one
18:18:37 <anish> JM: resolution to replace "Zero or more such headers may be used." to "Zero or more headers may be used".
18:18:56 <anish> JM: resolution to replace "Zero or more such headers may be used." to "Zero or one headers may be used".
18:19:43 <anish> sanjiva: it may be clearer to say header blocks may or may not appear on the wire. But this is editorial
18:20:31 <anish> daveo: replace header/header block
18:20:44 <JacekK> JacekK has joined #ws-desc
18:21:33 <dorchard> Zero or one such header blocks may be used
18:22:08 <anish> JM: for LC340 correct the plural, replace 0 or more with 0 or 1 + editorial
18:23:29 <anish> ... for LC339 we say that it is 0 or 1 and if you want more use modules
18:23:59 <anish> roberto: this is a burden -- to write a module spec and get interop
18:25:24 <anish> glen: we could reuse the 'required' attribute (no NS) -- same as wsoap:module
18:26:52 <JacekK> oh, if it had html media type 8-)
18:28:13 <anish> anish: are folks (like WSS TC) defining soap modules
18:28:29 <anish> sanjiva: no, but a module is not enuf for WSS, you need more like policy
18:30:33 <Roberto> Roberto has joined #ws-desc
18:30:33 <anish> JM: we are talking about adding a 'required' attribute similar to wsoap:module and a 'required' property. Default of 'false'. required='true' sets the required property to true.
18:30:37 <uyalcina> uyalcina has joined #ws-desc
18:30:43 <sanjiva> actually, module is enuf because that's really just another way of asserting a policy .. what I said is having 1..n wsoap:header things is not enough.
18:31:02 <anish> ... when 'true' it means that the service expects the header to be there.
18:31:31 <anish> ... if 'false' then the sender decides whether it should be there or not
18:32:29 <anish> (the above is a resolution for issue LC339)
18:33:58 <Marsh> ack hugo
18:34:13 <anish> hugo: this is a new feature
18:35:01 <anish> ... we also need to talk about the http header -- we have changed the syntax
18:35:02 <sanjiva> I disagree this is a new feature - we already have this capability if one is using wsoap:module, all we're doing it is increasing the convenience of the wsoap:header hack.
18:35:39 <anish> JM: is this a significant new feature that would impact going to CR after this?
18:35:56 <anish> sanjiva: this is not a new feature, we already have this in wsoap:module
18:36:19 <anish> glen: we are adding new functionality
18:37:13 <anish> JM: hugo do we need to go back to LC for this feature
18:37:57 <anish> hugo: that is a difficult Q to answer, we have to answer -- have we made a change this is significant and invalidate reviews. I don't think anybody would see this functionality and scream. I don't think this would force us to go back to LC.
18:38:15 <anish> JM: anybody else think that way?
18:38:20 <anish> daveo: i agree with hugo
18:38:28 <anish> anish: i agree with hugo
18:38:41 <sanjiva> +1
18:38:57 <anish> JM: ok, what I'm hearing is that this won't force us to go back to LC
18:39:12 <anish> JM: we also need to talk about changes to HTTP header
18:39:47 <anish> JM: any complexity in transfering this feature to the HTTP binding?
18:40:36 <anish> JM: proposal to add the required attribute (and all the component stuff) for wsoap:header AND http header
18:40:56 <anish> JM: any objections
18:41:25 <anish> no objections
18:41:47 <anish> RESOLUTION: issue LC339 and LC340 resolved with the above proposal
18:42:14 <pauld> pauld has joined #ws-desc
18:42:24 <anish> Topic: RDF Mapping (report from Jacek?)
18:44:00 <Roberto> http://lists.w3.org/Archives/Public/www-ws-desc/2005Sep/0046.html
18:44:57 <anish> Bijan presents http://lists.w3.org/Archives/Public/www-ws-desc/2005Sep/att-0046/wsdl-rdf.html__charset_ISO-8859-2
18:47:00 <uyalcina> uyalcina has joined #ws-desc
18:50:46 <anish> slide of the presentation: http://lists.w3.org/Archives/Member/w3c-ws-desc/2005Sep/0016.html
18:58:16 <pauld> pauld has changed the topic to: Web Services Description Working Group Face to Face, Palo Alto, 617 761 6200 code 97323, Agenda: http://lists.w3.org/Archives/Public/www-ws-desc/2005Sep/0040
18:58:25 <Arthur> Jack said that there is no need for the Description component, however I think it is important since it acts as a container for all the top level components in a component model instance
19:05:08 <jjm2> jjm2 has joined #ws-desc
19:05:13 <JacekK> JacekK has joined #ws-desc
19:09:29 <anish> Issue -- spec simplification about content type
19:09:42 <anish> arthur: media-type is irrelevant for this
19:12:28 <JacekK> q+
19:14:34 <Marsh> ack jac
19:16:16 <anish> bijan: the issue is if you have a frag identifier, do you need the media type?
19:16:43 <anish> daveo: u don't have to have the media type
19:16:50 <anish> ... u can guess
19:18:31 <anish> Everyone (who were paying attention) agree that this is not an issue
19:19:25 <dorchard> I now know the key phrases to listen for when talking about frag-ids and URIs "then you get the media type to interprent the frag-id" bzzzzt.
19:21:24 <anish> JM: the question is -- how do we get a broad review of this. One needs a good understanding of RDF and OWL to do this.
19:21:34 <anish> ... how do we engage the right people to review this?
19:21:54 <anish> ... let's do that after lunch
19:22:31 <anish> Jacek: can we do this tomorrow?
19:23:30 <anish> LUNCH
19:23:32 <anish> ----------------------------------
19:23:38 <Zakim> -Hugo
19:23:40 <Zakim> -Jacek
19:23:41 <Zakim> -F2F
19:23:50 <Zakim> -Canon
19:23:51 <Zakim> WS_(F2F)12:00PM has ended
19:23:53 <Zakim> Attendees were +1.650.846.aaaa, Hugo, F2F, Jacek, youenn, Canon
19:48:34 <dorchard> dorchard has joined #ws-desc
20:16:47 <Zakim> WS_(F2F)12:00PM has now started
20:16:54 <Zakim> +[TIBCO]
20:17:40 <Roberto> Roberto has joined #ws-desc
20:18:58 <sanjiva> Topic: Issue 327
20:19:07 <anish> s/327/LC327/
20:19:09 <Zakim> +Hugo
20:20:08 <uyalcina> uyalcina has joined #ws-desc
20:21:08 <kliu> kliu has joined #ws-desc
20:21:18 <sanjiva> Jonathan explains the issue: inconsistency in being required and defaulting to ""
20:21:19 <bijan> bijan has joined #ws-desc
20:22:50 <sanjiva> Arthur: explains the diff between being required in the component model and having a default value for it which means it may not have to be in the XML.
20:23:21 <sanjiva> Sanjiva: this is how it should be in this case ..
20:25:05 <sanjiva> Amy: if there is an auth scheme then there is a realm always. Therefore its correct as it stands.
20:25:56 <sanjiva> Amy: Its possible to configure a server to have "" as the realm of an auth.
20:26:10 <sanjiva> Hugo: proposes to make the property be optional.
20:26:23 <sanjiva> Amy: Why do u want to remove the "" default value?
20:27:58 <sanjiva> Hugo: Likes to think that props in the component model are props that are needed. If there is no auth scheme then having the property around is unnecessary.
20:28:59 <Arthur> q+
20:29:33 <sanjiva> Sanjiva: Hugo's proposal is to clean up the case of having an unused property when auth scheme is none.
20:31:18 <sanjiva> Arthur: Notes that {http authentication scheme} is required. Therefore treating the special value "none" with a special rule for realm makes sense.
20:32:39 <sanjiva> ... So the option could be to make both optional, drop "none" as a value for scheme and follow the logic thru.
20:32:46 <sanjiva> Amy: +1s it
20:32:52 <Roberto> q+
20:33:08 <uyalcina> +1 to Arthur's proposal
20:34:04 <sanjiva> Jonathan: Notes that in other cases we've made an effort to have a value to indicate no value .. hence the token "none".
20:34:23 <sanjiva> Arthur: points out that we're not overloading the situation - so its an easy cleanup
20:34:29 <sanjiva> Jonathan: PROPOSAL:
20:34:40 <sanjiva> ... 1. make auth scheme and realm both optional
20:35:04 <sanjiva> ... 2. auth scheme and auth realm properties exist together
20:35:20 <sanjiva> ... 3. drop the value "none" from auth scheme values
20:36:13 <sanjiva> ... 4. we use the default value of the attribute to provide the default value for realm (of "")
20:36:54 <sanjiva> Roberto: Suggests cleaning up the component model by introducing an http authentication component with two properties (schema and realm)
20:36:58 <sanjiva> Amy: +1
20:38:15 <sanjiva> Arthur: getting perverse, suggests that the component model could be object oriented much better
20:38:29 <sanjiva> Roberto: Notes that the Zee (or was it Zed) would be too hard to handle that case.
20:38:42 <charlton> +1 to the proposal
20:39:45 <sanjiva> Chad: wake up
20:39:55 <sanjiva> Straw poll:
20:40:02 <Roberto> chad, invite
20:40:03 <sanjiva> .. 1: make a new component with two props
20:40:37 <sanjiva> ... 2: cleaned up two properties (co-dependent as proposed earlier)
20:41:02 <sanjiva> .. 3: single property which is a pair of strings
20:41:40 <chad> chad has joined #ws-desc
20:41:43 <sanjiva> Anish: impact w.r.t. CR? 
20:41:51 <sanjiva> Jonathan: No syntax change so its fine
20:41:58 <alewis> chad, new poll
20:41:58 <chad> new poll
20:42:15 <sanjiva> Arthur: For consistency, every component in part 1 corresponds to an element
20:42:36 <sanjiva> ... the proposed option 1 breaks that consistency.
20:43:15 <alewis> chad, question: which of the following solutions is preferred to solve the inconsistency in description of http auth scheme/realm?
20:43:32 <alewis> chad, option 1: make a new component with two properties
20:44:00 <alewis> chad, option 2: clean up the two properties (make them co-occurrent and optional)
20:44:49 <alewis> chad, option 3: create a single property which contains two values, both strings
20:45:45 <sanjiva> Umit: what's the cost of these options?
20:46:02 <sanjiva> Jonathan: None of these changes the syntax .. so its "low cost"
20:46:23 <uyalcina> uyalcina has joined #ws-desc
20:46:42 <alewis> chad, option 0: close with no action
20:47:11 <Marsh> chad, options?
20:48:05 <dorchard> vote: 1
20:48:15 <Arthur> vote: 2, 1, 0
20:48:17 <Roberto> vote: 1, 2, 0
20:48:19 <bijan> vote: 3
20:48:26 <uyalcina> vote: 2, 1, 0
20:48:33 <TonyR> vote: 2, 1
20:48:36 <RebeccaB> vote: 1,2,0
20:48:41 <Allen> vote: 2
20:48:42 <alewis> vote: 1, 2
20:48:54 <pauld> vote: 1
20:48:58 <sanjiva> vote: 2,0
20:49:07 <kliu> vote: 2, 0
20:49:09 <charlton> voteL 1, 2, 0
20:49:10 <hugo> vote: 2, 0, 1
20:49:13 <charlton> vote: 1, 2, 0
20:49:17 <Marsh> 3, 2, 0
20:49:51 <Marsh> vote: 3, 2, 0
20:50:00 <Marsh> chad, count
20:50:00 <chad> Question: which of the following solutions is preferred to solve the inconsistency in description of http auth scheme/realm?
20:50:01 <chad>     Option 0: close with no action (0)
20:50:01 <chad>     Option 1: make a new component with two properties (6)
20:50:01 <chad>     Option 2: clean up the two properties (make them co-occurrent and optional) (7)
20:50:01 <chad>     Option 3: create a single property which contains two values, both strings (2)
20:50:03 <chad> 15 voters: alewis (1, 2) , Allen (2) , Arthur (2, 1, 0) , bijan (3) , charlton (1, 2, 0) , dorchard (1) , hugo (2, 0, 1) , kliu (2, 0) , Marsh (3, 2, 0) , pauld (1) , RebeccaB (1, 2, 0) , Roberto (1, 2, 0) , sanjiva (2, 0) , TonyR (2, 1) , uyalcina (2, 1, 0) 
20:50:06 <chad> Round  1: Count of first place rankings.
20:50:08 <chad> Round  2: First elimination round.
20:50:11 <chad>           Eliminating candidadates without any votes.
20:50:12 <chad>           Eliminating candidate 0.
20:50:14 <chad> Round  3: Eliminating candidate 3.
20:50:16 <chad>           Candidate 2 is elected.
20:50:18 <chad> Winner is option 2 - clean up the two properties (make them co-occurrent and optional)
20:50:49 <Roberto> chad, details
20:51:55 <sanjiva> Jonathan: is option 2 good enough to go forward with?
20:53:14 <sanjiva> Consensus achieved!
20:53:45 <dorchard> BC STV apparently didn't get very high score on the "litres/100km" rating.
20:54:52 <charlton> agreed
20:55:27 <sanjiva> Editorial AI: clean up the wording of the "Relationship to WSDL Component Model" to properly use the word component and property correctly and carefully.
20:55:36 <sanjiva> Issue is closed with this resolution.
21:00:20 <sanjiva> Topic: Issue 336
21:04:06 <kliu> kliu has joined #ws-desc
21:04:47 <sanjiva> Glen: Should be possible to annotate any endpoint (such as an EPR) with wsdlx:{interface,binding} not just a URI. Spec restricts to being able to annotate a URI.
21:05:37 <sanjiva> Umit: The spec should not imply that this is the only case these attrs should be utilized; can be used anywhere.
21:05:54 <sanjiva> Proposal: take the 2nd option and soften the spec to allow these to be used anywhere.
21:07:35 <sanjiva> Umit: will we explicitly refer to an EPR here?
21:09:38 <sanjiva> All: Yes we will refer to it. Stop being anally retentive about it.
21:10:11 <sanjiva> Issue closed with the above plan.
21:11:47 <sanjiva> Umit: we're ahead of the schedule and therefore we should go ahead and start drinking.
21:12:49 <sanjiva> Jumping ahead to tomorrow afternoon
21:12:56 <sanjiva> Topic: Issue 335
21:16:09 <sanjiva> Jonathan: Proposal is to offer a shortened component designators, but notes that it doesn't work because we allow different symbol spaces in the same TNS.
21:16:30 <sanjiva> DaveO: If people adopt some constraints then component designators can be simpler. 
21:17:08 <Arthur> Dan wants: http://www.w3.org/2005/08/sparql-protocol-query#SparqlQuery
21:17:23 <Arthur> We have: http://www.w3.org/2005/08/sparql-protocol-query#wsdl.interface(SparqlQuery)
21:17:31 <sanjiva> Jonathan: Go for it- if the context can constrain the scope to a world where restricted names occur. 
21:19:05 <sanjiva> Several people note that the sample that was indicated in the issue is inconsistent.
21:20:22 <sanjiva> Arthur: The proposal's attempt at installing the ID constraint doesn't work for WSDL because WSDL spans multiple documents.
21:21:02 <sanjiva> Sanjiva: Proposed to close the issue with no action.
21:21:15 <sanjiva> s/Proposed/Proposes/
21:21:52 <sanjiva> JOnathan: clarifying: proposal is to shortcut the component designators to make it easier for the simple case.
21:23:23 <Arthur> q+
21:23:44 <sanjiva> Jonathan: Keeping the designators and doing this will cause problems because it conflicts (the proposed designator is a valid XPointer and our syntax extends that.
21:26:15 <RebeccaB> q+
21:26:17 <sanjiva> DaveO: The proposal appears to be creating a default ID attribute ... for certain cases.
21:26:22 <Roberto> q-
21:26:22 <bijan> q+
21:26:33 <Roberto> q*
21:27:00 <Marsh> ack arthur
21:28:15 <sanjiva> Arthur: there are 2 scenarios for the xpointer. Case 1: component designator case xpointer does not apply. In this case its doable to say use the bare name as a shortcut for the case when top level components are unique.
21:28:30 <dorchard> q+
21:28:31 <Marsh> ack reb
21:28:44 <sanjiva> Case 2: for the case when the media type is present then its not possible to do this because it conflicts with XPointer.
21:29:00 <sanjiva> Rebecca: Does this affect last call? 
21:29:36 <Marsh> ack bijan
21:29:36 <sanjiva> Jonathan: We don't use component designators internally .. and since this doesn't go on the wire it probably will not demand another LC.
21:30:11 <sanjiva> Bijan: Alternate proposals that may satisfy this issue: Looking at it from an RDF view- having trailing parans is a problem.
21:30:44 <sanjiva> ... the real issue is to pack ugliness to the prefix and keep the last part clean. That would help the situatoin.
21:30:59 <sanjiva> Are parans illegal in RDF?
21:31:22 <sanjiva> Bijan: No. But it doesn't support the URI abbreviation syntax used in specs like SparQL.
21:32:47 <sanjiva> DaveO: schema also went thru a similar model .. but if the convention of uniqueness can be done then it can be supported for those cases when it works.
21:33:15 <Marsh> ack do
21:33:24 <sanjiva> q?
21:34:01 <sanjiva> Amy: proposal: if these are going to cause problems then can we move the component designatators in a separate deliverable?
21:34:55 <sanjiva> Jonathan: we voted to do that but didn't do it before because there was no public WD of the RDF mapping. We can move it to the RDF doc.
21:35:37 <sanjiva> Hugo: pulling it out would require going back to LC.
21:36:36 <sanjiva> DaveO: two options: change the spec or reject the comment saying "doesn't work for WSDL"
21:37:01 <sanjiva> Jonathan: Notes that these are not the only identifiers that can be used for WSDL2 components .. others are welcome to define their own.
21:38:42 <sanjiva> Bijan: appreciates the power and cleanliness of what we have
21:39:06 <sanjiva> Sanjiva: +1
21:39:24 <dorchard> I'll point out for the record that we do not have any web arch documents explaining why parenthesis are "bad" in URIs.
21:39:31 <charlton> +1 - we should close, no action
21:43:48 <sanjiva> Resolution: close with no action
21:43:57 <sanjiva> ACTION: DaveO to draft a response and send to the WG
21:45:18 <sanjiva> Topic: Issue 345
21:50:25 <sanjiva> Sanjiva: it appears that we can do this already
21:50:33 <sanjiva> Postpone until tomorrow for clarification.
21:50:34 <Marsh> ack hugo
21:50:34 <Zakim> hugo, you wanted to say that they are right
21:53:50 <sanjiva> Topic: Issue 344
21:54:37 <hugo> OK, I am confused: SPARQL uses application/x-www-form-urlencoded and we defined application/x-www-urlencoded; what's the difference?
21:55:11 <sanjiva> Hugo: we define --form-- too; see http://www.w3.org/TR/2005/WD-wsdl20-adjuncts-20050803/#_http_binding_default_rules
21:55:12 <Zakim> -Hugo
21:56:00 <hugo> oh, I see; it's a typo in the SPARQL spec talking about ours then
22:24:07 <uyalcina> uyalcina has joined #ws-desc
22:28:57 <sanjiva> ACTION: Editors to examine use of "Note that" and review those to make sure those are not interpreted as non-normative notes.
22:31:46 <sanjiva> Comment 1 of Issue 344: accepted
22:32:05 <sanjiva> Comment 2 of Issue 344: see action item 3
22:36:21 <sanjiva> Comment 3 of Issue 344: closewith no action
22:36:55 <kliu> kliu has joined #ws-desc
22:37:12 <sanjiva> Arthur recommends noting that the same paragraph has been clarified in response to another issue.
22:39:21 <sanjiva> Comment 4 of Issue 344: proposed refactoring closed with no action.
22:47:25 <RRSAgent> See http://www.w3.org/2005/09/26-ws-desc-irc#T22-39-21
22:54:45 <sanjiva> Comment 5 of Issue 344: 
22:56:34 <sanjiva> Discussing the scope of {style} .. is it required to be understood
22:57:24 <Arthur> q+
22:57:35 <Marsh> ack art
22:57:56 <sanjiva> Jonathan: if the style attribute is not understood by a consumer, there's no need to do anything about it
22:58:40 <sanjiva> Arthur: Style documents how the messages were defined and one is welcome to ignore them
22:58:49 <sanjiva> Umit: RPC style defines some constraints on the schema
22:59:27 <sanjiva> Arthur: If u understood the style u can determine whether the messages conform to the style. But you don't need to understand the style at all to process the messages.
23:00:05 <sanjiva> .. Individual styles are like extensions and hence a validator should treat them that way.
23:00:45 <sanjiva> .. The comment is about having two or more styles: then there can be a conflict. 
23:02:46 <sanjiva> ... The solution is to say that the combination SHOULD be consistent.
23:03:53 <alewis> q+ to raise a separate issue after the resolution of this issue
23:06:46 <sanjiva> Glen: Even if there's only one style, the spec must be very clear that the {style} stuff is optional from the point of view of the consumer.
23:07:41 <sanjiva> Jonathan: We seem to be in agreement that we should clone the F&P composition note pointed to by Arthur should be copied to the style stuff.
23:08:05 <Arthur> q+
23:08:15 <sanjiva> Tom: Style is an assertion but it must be adhered to be a valid document.
23:08:32 <sanjiva> Glen: But just like any other extension element, this is an optional extension.
23:08:56 <sanjiva> .. this becomes a problem IFF one defines style as a required extension.
23:09:49 <sanjiva> Sanjiva: We should note that styles are an optional extension. 
23:10:05 <sanjiva> Optional extensions are ignorable by the client already.
23:12:56 <sanjiva> Umit: Wants to make sure that if the tool does understand a style URI then it MUST fault if the style is not followed.
23:13:37 <sanjiva> Arthur: In the case of the reported probem, the document is indeed invalid because its not following the rules.
23:13:51 <sanjiva> Jonathan: proposal to fix :
23:13:56 <sanjiva> .. 1. remove "it is an error"
23:14:11 <sanjiva> .. 2. move the stuff from section 6: if things compose u might get yourself screwed
23:14:21 <sanjiva> .. 3. styles are optional extensions
23:14:48 <sanjiva> s/2\. move/2. copy/
23:16:00 <sanjiva> ACTION: Arthur to draft above as a proposal to be able to close this issue
23:16:03 <alewis> I have a problem with the initial sentences/paragraphs of part two, sections 4.2 and 4.3 (IRI style and multipart style).  Both say that the styles apply to any MEP with an initial message.  This is *weird*.  What is an MEP without an initial message?  Is such a thing possible?
23:20:05 <Marsh> zakim, who's on the phone?
23:20:05 <Zakim> On the phone I see [TIBCO]
23:20:12 <Zakim> -[TIBCO]
23:20:13 <Zakim> WS_(F2F)12:00PM has ended
23:20:15 <Zakim> Attendees were [TIBCO], Hugo
23:21:00 <sanjiva> Amy: questions the first sentence of section 4.2 of part2 .. the last 2 words seem to make the sentence are totally useless.
23:21:48 <sanjiva> ACTION: editors to look at sections 4.2 & 4.3 of part2 and see whether the first setences (paragraphs) are no-ops.
23:24:33 <sanjiva> ACTION: editors to fix the first paragraph of section 4 .... does not make sense at all right now.
23:27:51 <sanjiva> Tom: Notes that there's an inconsistency in section 4.1.2 because the abstraction of signature stuff doesn't match with the syntax
23:28:33 <sanjiva> Basically change all the (q,t)'s to (t,q)'s
23:30:10 <sanjiva> Apparently its correct schema-wise but the schema's union stuff can be written in the other order to make it slightly easier for those of us who are not speaking schema in their sleep.
23:30:24 <sanjiva> ACTION: Roberto to fix the schema in 4.1.2 accordingly.
23:31:45 <sanjiva> Comment 6 of 344: Closed with no action
23:35:54 <Allen> Allen has joined #ws-desc
23:36:41 <sanjiva> Comment 6 of 344: Arthur to look at the text and clean it up
23:37:05 <sanjiva> ACTION: Arthur to edit 2.7.1 and capitalize capitalize feature appropriately and define "feature" somewhere.
23:38:19 <sanjiva> Comment 7 of 344: Closed with no action (because of precedence for IRIs)
23:40:12 <sanjiva> Comment 8 of 344: We agreed but we've dug this pit and we're going to lie in it. Its such a great pit that we can't see the light outside of it.
23:40:53 <charlton> This is splitting hairs
23:41:37 <charlton> I agree, this one is out of a Marx Brothers screenplay
23:43:23 <sanjiva> Comment 9 of 344: Remove last sentence of paragraph 6 of section 2.9.1
23:45:41 <sanjiva> Comment 10 of 344: Damn we've been sleeping for too long. Accepted.
23:48:11 <sanjiva> Comment 11 of 344: leave it as is
23:53:44 <sanjiva> Comment 12 of 344: close with no action, although it is possible some improvements may occur when Arthur adds test assertion markups.
23:59:58 <sanjiva> Comment 12 of 344: UNCLOSED. Arthur to look for simplification options.