See also: IRC log
<anish> Scribe: Arun
Mark: Discussion of going to last
call
... added to the agenda.
Anish: Any more info on June F2F ?
Chair: Week of May 30th, need to decide scheduling with WSDL F2F.
Chair: Will be decided by the end of this week.
Chair: Preference is to go later in the week
Philippe, Mark Peel, Arun, Prasad not attending Berlin
Umit: Steve is travelling today
<pauld> i'd really prefer not to travel whit-week
No joint meeting between WSDL and WS-A planned for now in Berlin
Jonathan: Dont want to rule it out since there is so much overlap
People need more time to review
scribe: to be reviewed next week.
Harris owned the issue ...
scribe: looking for a new owner.
Looking for an owner of test suite along with issue 041.
Accepted couple of proposals ...
we want to accept rest of the issue ?
Accepted proposals 1 & 2, deffered 3 & 4 ?
3: Add attribute block default to addressing schema
Understanding is that it makes it final in the schema
Dave: Turns off substitution
groups ...can be turned explicitly for each individual element
...
... thinks this is a common idiom.
Nobody object to the proposal
RESOLUTION: accept proposal part #3
4: Added element form default qualified
Jonathan and Anish thinks this is a bug in the current addressing schema
<uyalcina> +1
Dave agree as well
Nobody objected, added element form default = qualified
RESOLUTION: accept proposal part #4
Jonathan added another twist ... retryAfter attribute with a nonNegative Integer
scribe: do we need all the range specified by nonNegative Integer ?
Proposal is to change to unsignedLong
There was discussion on the mailing list regarding different data types.
<TomRutt> +1
<TomRutt> not +1
Jonathan is happy with unsignedInt or unsignedLong
Anish: Question about schema 1.1 - how far is it in xsd:duration so that we can we use it in WSA ?
Tom: If you want, you can
restrict duration to seconds ... with an arbitrary
precision.
... thinks that it can cover all the cases. Prefers using
duration which is the preferred way.
Dhull: Usecase from Notification,
they allowed either a duration or an absolute time
... Should not use arbitrary integers, but instead
duration
... Should we use duration or absolute time ?
DaveO: In WS-Eventing, dateTime and duration are both permitted ...
<anish> Addtion duration subtypes in schema 1.1 -- http://www.w3.org/TR/2005/WD-xmlschema11-2-20050224/#yearMonthDuration
which version of duration to be used ... schema 1.0 or schema 1.1 ?
<anish> and http://www.w3.org/TR/2005/WD-xmlschema11-2-20050224/
<plh> (schema 1.1 datatypes last call is scheduled before the summer btw)
DaveO: Leaning towards using schema 1.1 if that fixes for us
<rsalz> +1!
<anish> ops the right ref to dayTimeDuration is: http://www.w3.org/TR/2005/WD-xmlschema11-2-20050224/#dayTimeDuration
Jonathan: Duration does not have natural mapping to programming language
<TomRutt> How do you know milliseconds will be precise enough four years from now?
Rich: Simplicity is important ... absoluteTime gives you the benefit without ambiguity
Dhull: If we use milliseconds, then we need similar unit of precision ...
might be interop concerns.
DaveO: Love keeping things
simple
... Dont need to suck in entire schema 1.1
<rsalz> Using XSD1.1 means I have to read the spec, tho.
If things are fixed in schema 1.1 that are the same kinds we need, then we got to use it
DaveO: ... If there is nothing,then we should not use them.
Umit: Eventing is using schema
1.0 duration ?
... recollection is 1.0.
Anish: Two advantages of using types in 1.1, both the types are ordered
Hugo: Schema 1.1 going LC before summer
Chair: Two general approaches ...
1). Use an integer and define the precision ...
2). Use duration
scribe: and a possible 3rd approach to accept absolute time.
Strawpoll: Who thinks dual appraoch is accepable ?
BEA is fine
Anish is fine
Umit is fine
<plh> +1
IONA
<rsalz> rsalz can live with it :(
IONA is fine with it
<mlpeel> Novell can live with it
Rich: Either an integer or an absolute date time, to avoid the ambiguity of duration.
Confusion in the strawpoll ...
<rsalz> FWIW, I prefer dateTime, unsignedInteger, duaration in that order
Chair: Does anyone prefer to have relative and absolute possible ?
BEA does
<TomRutt> fujitsu likes it
Oracle also
<mlpeel> Novell can live with this
HP also
<uyalcina> +1
<dhull> TIBCO is content
Fujitsu, IONA happy
Anyone think, this is a bad idea ?
Jonathan, Rich thinks yes.
Rich prefers absolute, Jonathan prefers relative.
Chair: Lets look at relative ...
<TomRutt> duration
UNKNOWN_SPEAKER: some form of int ...
Jonathan, Rich would like to see int
Who would like to see duration ?
Anish: schema 1.0 or 1.1 since there is ordering problem in 1.0 ?
<TomRutt> Ints have precision and range problems
DaveO: Rationale for Rich's opinion ?
Rich: miliseconds is fine enough level of detail, integer fits in all the platform out there
Rich wants to avoid duration ... because it's ambiguous ...
scribe: does not achieve the complex data type that we have.
Rich: For simplicity, avoid duration.
DaveO: Bug in schema 1.0 because
of lack of ordering in duration.
... Doesnt matter position
Jonathan: Does not like the approach of borrowing from schema 1.1
Anish: See the ordering problem of duration and restricting to miliseconds
DaveO: Use integer and say this is forward port to duration constructed to miliseconds
Tom: Somebody may like to go lower than miliseconds
<Zakim> Marsh, you wanted to ask how many validators can handle the 1.1 datatypes today.
<Zakim> anish, you wanted to answer daveo's question
Anish: Can live with DaveO's proposal
<mnot> Option 1: int-based field; implied unit is milliseconds
Chair: OPtion 1: Int based field of some sorts, implied unit is miliseconds
Tom: 32-bit or 64-bit ?
<mnot> Option 2: Schema 1.0 duration type
Option 2: schema 1.0 duration type, constrained or duration type ?
<mnot> Option 3: Schema 1.1 duration type
just the duration type, not constrained
<pauld> chad, say hi
Umit: total order problem with schema 1.0 duration
<pauld> chad, Option 1: int-based field; implied unit is milliseconds
Is it relevant to us ?
<pauld> chad, Option 2: Schema 1.0 duration type
<pauld> chad, Option 2: schema 1.0 duration type, constrained or duration type ?
Tom: Which element is it being used for ?
<pauld> chad, Option 3: Schema 1.1 duration type
Anish: retryAfter attribute on one of the faults
<TomRutt> for retry after the absolute time is ordered
<pauld> chad, question: type for retryAfter
<pauld> chad, list options
<pauld> vote: 1, 2
<Marsh> vote: 1
<rsalz> vote: 1
<uyalcina> vote: 2, 3
<pauld> vote: mickyMouse abstains
<dhull> vote: 2
<mlpeel> vote: 2, 3
<pauld> vote: mickyMouse: abstains
<MSEder> vote 1
<hugo> vote: 1, 2, 3
<plh> vote: abstains
<anish> vote: 2, 1, 3
vote: arun abstains
<TomRutt> tom vote 2, 3
<MSEder> vote: 1
<uyalcina> vote 2, 1, 3
<mnot> chat, prasad votes: 2
<mnot> chad, prasad votes: 3
<uyalcina> vote: 2, 1, 3
<NiloM> vote 3
<Marsh> vote: prasad: 2
<pauld> chad, say hi
<mnot> vote: yin-leng: 3
<mnot> vote: dave0: 1,3
<vinoski> vote: 2, 1, 3
<mnot> chad, andreas: 1
<mnot> vote: andreas: 1
<pauld> chad, voted?
vote: 2, 1, 3
<mnot> vote: tomR: 2,3
<pauld> chad, count
<chad> Winner is option 2 - schema 1.0 duration type, constrained or duration type ?
<pauld> chad, details
<Marsh> chad, details
<pauld> chad, you said that twice :-)
Tom: Should we constrain to
option 2 to seconds ?
... let people put the decimal point.
2.5 seconds, lexical form would be "2.5s"
Jonathan: Do we need to have a
"p" in front of it ?
... all the schema examples follow that convention.
... there is no way to constrain "s" to a value ?
Anish, Umit and others: Can do.
Anish: Is this decision independent of whether we are going to provide absolute or duration ?
Chair: We are just going to do duration.
<mnot> Schema 1.0 duration type: http://www.w3.org/TR/xmlschema-2/#duration
Jonathan: Second component allows arbitrary decimals and thus there is no upper bound.
Tom: Yes, that is the
problem.
... Do you want an upper bound ?
Jonathan: Yes
Umit: Cant we do just via facet ?
"Number of seconds can include decimal of arbitrary preision" from the schema spec
Jonathan: proposes that we should limit theupper bound
Chair: lexial or value ?
<rsalz> <pattern value="p{Nd}{8}S"> -- 8-digit seconds
Umit & Jonathan: does not matter
Chair: Do we limit it just to seconds ?
Hugo: Seems like we are limiting schema types in multiple ways.
<pauld> big +1 to a simple time_t type ..
Jonathan: Should allow days,
hours, minutes, seconds
... Concerns are upper bound, good programming language
represention from the schema type
Hugo: Does HTTP has rules like this, for instance Expires ?
Jonathan: Take it back to the list
Chair: Schema needs to be final when we go LC
Tom: Used only in EndpointUnavailable, if we limit the scope then we may be able to come up with a better solution
<pauld> chad, list votes
<pauld> chad, drop mickyMouse
DaveO: Need to identify the reasonable usecase and then propose
<Zakim> anish, you wanted to ask a question about choice between "duration" and absolute time
Dhull: Concerned by the sheer
amount of time it's taking
... look at other standards and see what they have done.
Tom: Who would care if it stays the way it is ?
Chair: Would Jonathan be ok in dropping the issue for now and leave it as is ?
<uyalcina> +1 to Jonathan's suggestion
CHair: Ask for feedback on the type
RESOLUTION: Drop this issue for now.
Any other issue would be a LC issue instead of a draft issue.
<rsalz> WS-SecConveration doesn't say anything other than "things may expire"
Anish: Did we accept #5 to make names consistent ?
Chair: Yes, we did last week.
Anish: On the list, we havent included wsa:type attr in our global schema ?
<rsalz> for ws-addr? i believe Gudge checked it in and it's on the WG page
Chair: Editors have been conveyed to change wsa:Type to wsa:isRefParam or something.
<plh> "Each header block added as a result of the above rule is annotated with a wsa:isReferenceParameter attribute whose value is "true"."
RESOLUTION: This unnumbered issue is closed.
Chair: Does this need to be discussed before LC ?
Everybody agreed it to be LC item ...
Decided unanimously to drop it from the issue list for LC.
<scribe> ACTION: Anish to write an email to Connor and CC the list. [recorded in http://www.w3.org/2005/03/07-ws-addr-minutes.html#action01]
Anish: explains the issue
... What does it buy us ...
... feels it buy us zero.
Anish feels Infoset should be good enough.
Chair: Coming late in the game because it's a big change from editor's standpoint.
Chair: Does the WG feel we should addressing before LC ?
UNKNOWN_SPEAKER: another question is should it dealt after LC ?
Hugo: If we remove section 2.1, what would we be talking about ?
Anish: We'll talk about wsa:address EII (in terms of infoset).
Jonathan: If we get rid of this
completely, we have to do little more surgery on the
document
... we'll hit the XML barrier anway.
Chair: If we were to do it, then we'll have to find out the changes ...
UNKNOWN_SPEAKER: who is interested in doing this ?
Anish is nominated by chair on this.
Anybody else ?
<TomRutt> I would prefer it , but could live with what we have
<Marsh> Anish has a point that this doesn't have high value, but I don't think it has zero value, and changes at this point have a cost.
Editors will go ahead and make the changes and if they face a block then we've to resolve it.
Anish: Whether the status quo is fine with people ?
Jonathan: Sees a value in it's current represetantion.
Dhull: Conflicted on this. If we talk about infoset, we bring a whole bag of attributes.
Jonathan: How does section 3 look different if we use infoset ?
Anish: Talking about 2.1
... abstract properties in 2.1, if there are extensibilty
elements then where do they go ?
... If infoset then that can be explained.
Chair: Dont want to resolve this right now since we are short of time.
Tom: Would like to see a complete proposal from Anish
Umit: Agrees with Tom ...
... how message addressing props are represented ?
<rsalz> Information model of SOAP is infoset. Prefer to see that same model used here.
Chair: Mostly a documentation, not an implementation issue. Can we move this to a LC issue potentially ?
Anish: We may have to go to
second LC if we change too much ...
... agree not an implementation issue ...
<uyalcina> My concern is how Section 3 will be affected and how we can talk about Message Addressing Properties easily as we can now.
Anish: agree to make it an editorial issue.
<Marsh> My position: Resolving this issue is not necessary to declare victory.
<Marsh> ... Therefore, drop it and ship it!
Either Anish come back with proposal and delay LC ...
scribe: or put it post LC issue.
Tom: Come back with a complete proposal next week
Anish: Are people opposed to
it?
... Can we remove abstract information model while in LC w/o
going to LC
<uyalcina> my motto is "if it aint broken, don't fix it". I want to make sure that we don't make the spec less readable, etc.
Hugo: We are not changing the
functionality of our technology so it is ok
... not sure though.
Chair: Do people want to see a proposal critical to go to LC ?
Strawpol: : Do we think this is criticial to go to LC ?
Anish - Yes
Rich - resolution one way or other
Tom - prefers it before LC
<pauld> don't do it
Jonathan, Mark Peel, Hugo , Dims- does not believe
<uyalcina> I am abstaining...
<MSEder> no
Vinoski - N
<NiloM> do it before LC
3 Y, 7 N, 4 A
Chair: Looking at the strawpoll, inclination is to not take this as an issue
UNKNOWN_SPEAKER: Anish to bring out a more
complete proposal during LC.
... not added to issues list.
... any other comments ?
Anish: Not very encouraged that
it would make it to the doc ...
... but will raise a LC issue the very first being it's not
extensible.
Dims: If we can come up with a proposal and see where others are in the WG and then deal with it.
Anish: Do we need a formal vote on this issue ?
Chair: If we take a formal vote then we will not be able to take this as an issue again.
Chair: Take a vote to have it on the issues list.
Jonathan believes it should not be on the issues list
5 N, 4 Y, 6 A
Chair: We will not add it to the issues list.
Defer since it's not in CP
Lots of discussion on the mailing list
<mnot> http://www.w3.org/mid/7DA77BF2392448449D094BCEF67569A506C16B29@RED-MSG-30.redmond.corp.microsoft.com
Jonathan: Seems to be general support proposal 3
Tom: Clarification if we leave it as is, if I'm bound to an HTTP Action then I've put anonymous in the Response
Jonathan: Yes
Hugo: Make ReplyTo optional ... there was some support but disagreement ..
<mnot> http://www.w3.org/mid/20050302152058.GR4520@w3.org
Tom: The crucial question, how important is to have the brute force in the header than knowing the MEP ?
dhull: Semantic difference
between missing and anonymous ?
... if there is no semantic difference, then it does not seem
to add anything.
... once people mplement it, they would interpret it.
... Either remove the URIs or explicitly say what the
difference is
Jonathan is ok with that
Tom: How important it is if there
is a one-way WSDL bound to an HTTP response ?
... feels it's kind of an edge case.
<dhull> +1
Tom: happy with dhull's statement.
Chair: Is it delta to existing proposal or a new proposal ?
Chair: can we resolve in 5 or 10 minutes ?
<TomRutt> yes
UNKNOWN_SPEAKER: extended by 10 miutes.
dhull: Show a difference between missing and anonymous or otherwise get rid of anonymous.
Chair: Hugo what is your view ?
Hugo: remove the URI
... removing the anonymous URI (if everbody agrees)
... have an optional ReplyTo.
Jonathan's proposal is orthogonal to this proposal.
dhull's propsal: Get rid of anonymous entirely
Chair: ReplyTo would be mandatory but there would be anonymous URI ?
If no reply endpoint is specified and formulating a reply, then you can send the reply back to recepient but conveyed out-of-band
Chair: It's a new proposal
Hugo is trying to understand how different it is from his proposal ... it is not.
Chair: Do we have confidence that this close the issue ?
<Marsh> Section 3.2 bullet 1a:
<Marsh> REmove second sentence.
<Marsh> Add text fthat we currently use in describing the anonymous URI here instead.
<Marsh> Remove text defining the anonymous URI
<Marsh> Add to bullet 2b text (ala JMarsh) making FaultTo fall back to ReplyTo
Chair will instruct Marc to add the text tothe draft
David will send other details to the mailing list
Chair: There is still confusion around this issue
<dhull> http://lists.w3.org/Archives/Public/public-ws-addressing/2005Mar/0018.html
<scribe> ACTION: Tom to summarize the proposal concretely, with deltas to the propsal [recorded in http://www.w3.org/2005/03/07-ws-addr-minutes.html#action02]
WIll seek support for LC next week