See also: IRC log
2 issues remaining on framework document
Have primmer issues also
lets start with issue 4238
<Fabian> does somebody have a URL to today's agenda?
Asir to present issue 4238
there are 2 new issues with the primer, submitted by William
<maryann> link to mail from asir ---http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/0184.html
Asir explains the policy operator and its extensibility
Asir explains the exactlyOne with no extensibility
Arir explains the All operator with no extensibility
ChrisF asks if the child policy element allows extensibility
Monica asked that it be mapped to schema
<maryann> umit: compact form is about normal form but we talk about normal form first, so we should reorganize the scetions for readability
<maryann> asir- there will be too many forward references
cferris there are no backwards ref in the proposed edits
asir go to full spec
monica lets look at the table of contents
asir propse that new title of 4.3.6 its titles is nomilization
<maryann> asir - with input from umit- move new text to 4.3.6
<maryann> chris --- should 4.3 go before 4.1
asir - we have the data model then get into compact form
<maryann> asir - normal form is a subset of compact form
<maryann> chris - time out
<maryann> chris- we need to follow the q
<maryann> fred is on the q
Glen - how is subset term being used ?
<dorchard> Dave: how is the subset term being used
<maryann> chris - no free for all
we are getting a tutorial on how conversations are working
<maryann> fred: the proposal shows there is no attribute extensibility for exactly one
<maryann> fred- do we need a statement in the framework?
Fredericks propsal shows no extensibilty for exactllyOne, need to add
<maryann> dave- a note?
<maryann> fred- we need a sentence to explain it
<maryann> asir - fred wanted a note to explain why extensibility is not in ALL and exaclty one
<dorchard> something like: Note: The normal form does not have an extensibility point because the extensibility point in the compact form is transformed into an assertion.
<maryann> prasad- if we look at 4.3 in asir's proposal- it makes a statement about a wrapper element that might not alwyas be true
<maryann> change "variety" to zero or more
prasad schema policy outline, why is the compact form in brackets
<maryann> prasad - schmea outline of wsp:policy element, why is it in brackets?
prasad global change
roth likes how the current document outline flows
<maryann> dan: wanted to comment on current structure, try to introduce one concept and then build on it
<maryann> dan: give syou the simplist concept and then adds the "syntactic" sugar
roth likes how it builds, and layers the complex forms
<maryann> data model, normal form, then compact form makes sense
orchard has no opinion
<maryann> correction not much of one :-)
<maryann> dave- there is a mix of readers
orchard: folks will author in compact and implementors will do normal form, so what is target of doc
dave: schema not valid for normal form
<maryann> dave- compact form allows a broader set than the normal form
<maryann> glen- but we only say that by implication
<maryann> asir- primer takes the opposite path, it takes the compact form first
<maryann> umit- we are contradicting ourselves,
<maryann> in the primer we go in one order and in the framework another
<maryann> intoduce the normal form AFTER the compact form
<maryann> both are data models
<maryann> and there is a transformation from one data model to another
<maryann> we should talk about what happens to extensiblity in that transformation
<fjh> Should clarify how extensions work across transformation of model from compact to normal form (or in both models)
<fjh> +1 to umit
<maryann> fred- umit has captured what i was trying to say
<maryann> asir a policy in the normal form is a valid compact form
<maryann> dave- the schema for the normal form is overly lax
<maryann> flen- dave mentioned that extensions turn into asserions
<maryann> glen- that's magic that is not stated
<maryann> glen- spec lacks a processing model for dealing with extensions
glen gave an example of adding an extension that does not turn into an assertion
chris time out
<maryann> glen- we have assertions and extensions as two things
glen don't have a unified model in respect with assertions and extensions
<Fabian> thanks Chris
<umit> glen, could you write it down? I think you made a very important point
dave - 2 type of extensions, ones that are assertions and ones that are not assertions
glen so how do you know what to do with the non assertion
dave: thinks that there is a bug in the framework
chris: it would be useful to have
the primer and the framework docs match, but would be usefull
to have a note in 4.2 to say that the compact form is
consistent with schema
... and the normal form is not
... can go with reordering (compact, normal, nomalization)
asir: we will have forward references
chris: and that is a problem ?
monica: agrees with chris, no
comments in the schema
... need to add documentation on the schema
dan: why do folks want to change the order ?
chris: because its in the same
order as schema
... its just a better flow
dan: framework doc comes first
and then the schema so folks will look at the framework doc
first and that you have to read the spec to understand the
... wants to keep things in layers, so the doc read better as is now
fsasaki: agrees with dan
chris: add a note about the target readers
umit: there are different types
of framework implementors, so are we interested in both compact
and normal forms
... there is a whole tooling side
chris: is attempting to write new text
fjh: should text say that 4.3 is about compact form (for policy authors)
<scribe> new text discussions
giving folks time to review new text
<cferris> The normal form (see sect. 4.1) of a policy expression is the most straightforward XML Infoset representation of the policy data model. Equivalent, alternative representations allow policy authors to compactly express a policy (see section 4.3). Policy authors might be more interested in the compact form (seesection 4.3), where the outlines and definitions describe what is valid with regards to the policy language XML Schema.
<cferris> the above is the proposed second paragraph for sect 4
asir: summary of all changes
<fsasaki> break for 20 minutes
<umit> umit's addition to Chris's:
<umit> While the policy language XML Schema is a representation of the compact form, the normal form is more restrictive as outlined in Section XXX.
<fsasaki> back again, end of break
starting back up now
... still wordsmithing new proposal
... we have asir's update, we have 4 updates and new text proposal by chris
... anyone against proposal ?
monica: want to make sure we have enough to explain the ## in the compact form
chris: missing ellipses
<maryann> monica: we don't need the last section (if an element is not recognized....) its already above
<maryann> chris: any other comments?
<maryann> chris: any objections to resolving with this proposal?
<maryann> monica: do we need a new issue?
<maryann> chris will send a note with details
<maryann> this is to resolve asir's proposal ( http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/0184.html)
<cferris> RESOLUTION: 4238 and 4196 closed with http://lists.w3.org/Archives/Public/public-ws-policy/2007Jan/0186.html
chris: no more LC issues
chris: Paul outlined some proposed dates
nadalin: do we need more time to review document, is a week enough ?
<fsasaki> fsasaki: we vote for CR on the 7th, we can meet the current schedule (CR publication in the if week of the 19th)
monica: some update to the primer
may effect the spec
... how do we monitor the time?
chris: so this gives us 3 weeks, we have until next Wed to produce CR and then 2 weeks to review
maryann: how often are the director meetings?
chris: they are when we can get them
<cferris> asir: two sets of changes; the changes leading up to the f2f in the current EDs and the changes resulting fom the resolutions to the issues closed in the f2f
<cferris> asir: tony, do you have issues with the first set?
<cferris> tony: the wssx tc needs time to look at the updates to the LC draft
<cferris> tony: the wssx tc hasn't had a chance to review the wssx tc specs in light of the revised policy specs to see if there are conflicts
<cferris> asir: if editors can get revisions done by weds, and approved a week later, paul and chris can request transition first week of feb and exernal groups can review CR drafts during CR
<cferris> tony: what if there are requested changes?
<maryann> felix: from a reviewers perspective its best to do as late as possible
<maryann> felix: from a group perspectiver there is a risk in late changes
<maryann> felix: we could take an action to inform them of the changes
<maryann> tony: but I don't think we can do that in a week
<maryann> tony: i don't think there's enough time
<maryann> felix: we could work together and prepare a mail
<maryann> tony: we would have to see what timeframe they could respond in
<maryann> felix: i agree, we can start earlier to give them more time
<maryann> tony: any thing to speed things up
maryann: wants to understand why
we can't take more time
... we need to look at all the documents
... is not supportive of months of delay but from March to April is not that bad
<fsasaki> chris: paul went through our schedule yesterday, from our march f2f backwards
<fsasaki> .. expecting that interop would be co-op with march f2f (chris channeling paul)
maryann: is there a linkage between interop and CR
<fsasaki> .. candidate rec is synynomous with a "call for implementation"
<fsasaki> chris: in addition of publication of the draft, we need to indicate a list of features at risk and expect to have interop testing
<fsasaki> .. a f2f is a good time to do interop testing
<fsasaki> .. it was anticipated that we publish a CR draft roughly a month before the f2f
<fsasaki> .. (by Paul)
maryann: is 2.5 weeks enought to implement the scenarios ?
<fsasaki> fsasaki: we are also chartered to publish in march the CR draft
<maryann> tony: concern that we haven't seen the scenarios and 2.5 weeks is not enough time
<maryann> asir: tony expressed sxtc question, nothing stops them from raising issues and nothing stops us from raising proposals and fixing these
<maryann> chris: felix said there are 2 options, remove a feature that has been marked at risk
<maryann> asir: nothing stops us from making changes
<maryann> chris: its a different thing to say we can change the spec from we change the spec and go back to working draft
<maryann> asir: maryann questioned moving content and we didn't do that
<maryann> asir: interop issues will turn into bugs
<maryann> asir: tony said we haven't seen the scenarios
<maryann> asir: for the march interop paul said we don't have to do all the testing we can only do a subset
<maryann> asir: paul outlined a schedule, that is reverse engineered
<maryann> asir: and all the issues have had concrete proposals
<maryann> chris: what felix has said is that Steve, who is doing the review has said the only date he has is in the week of Feb 19 or later (earlier is difficult)
<maryann> that means we have till the 12th to produce the CR draft
<maryann> chris: you are asserting that we have to agree on the 31st, but now we don't have to
<maryann> the publication can not happen until after the review
<maryann> frederick: is it correct to say in a complicated area and we get it right, we lose big time>
<maryann> and if we take the time and do it right we win bigtime in the long run?
<maryann> felix: if you play russian roulette, you can start implementing anytime, some working groups start implementing in the beginning and then they increase, the groups can do it different ways
<maryann> felix: you can start at any time
<maryann> felix: i'm not aware of the process of how you deliver to your engineering team
<FrederickH> what I said was that if we make a basic mistake discovered after CR, then we lose much time, rather than a short delay before CR to get it right
<maryann> monica: i think we have to ballance whether we come up with whether or not to leave out things, that we might put at risk
<FrederickH> In addition, however, some implementation could start before CR
<maryann> monica: if we find substance gaps, it could be a big issue, but we need to balance these issues
<maryann> monica: i'm in favor of going forward
maryann: issue about the
developers, we are depend on the security domain, so the reason
that we are at risk is that we have to get these folks in the
boat, so round 3 is very important
... concern that security domain is not enough, may need other domains
... maybe we split the interop
<cferris> umit: schedule worked backwards from march... there are several rounds... march is supposed to be the first round... what are the other targets... if we get out of CR in july, what is the rest of the schedule? when are the other interop phases?
<cferris> felix: no need to have the scenarios in TR space... paul said that it would/should be linked from the public page and in CVS... would like html *very much*, but could be word or pdf
<cferris> umit: who is going to be responsible for making that happen?
chris: the spec writter and implementors are different beasts
<maryann> chris: i asked that the working group assess the change in phases and they need to be looking to include new people as part of the working group to support the interop phase
chris: some companies may have resource issues
<maryann> chris: there is no limit on how many people from a company can attend
chris: but one vote per company
asir: wants to take this up to the chairs
umit: what is march f2f interop
going to address, phase 1 ? phase 2?
... maybe security comes later
chris: we have a F2F before we
would exit CR and we would have a another interop before we
... we can only look at what we are doing in March and that is round 1
<maryann> felix: how long are you (tony) asking for?
<maryann> felix: looking at the charter there is no impact
<maryann> asir: i looked up the archive as to when the note was sent to the tc --- Nov 29th, reminder on Dec 22nd
<maryann> another reminder on jan 12
<maryann> asir: if the working group wants 2 weeks to review that's fine
<maryann> asir: we've discussed for a long time about this
<maryann> asir: editors to produce new drafts next week
<maryann> asir: new issues can be raised at the CR
<maryann> chris: yes, but you then impact the spec possibly going back to working draft
<maryann> asir: that's something you can ask, we can go to CR and we can raise issues at that point
<maryann> chris: propose a working lunch
<maryann> chris: everyone grab a slice
<Fabian> when are we reconvening?
<cferris> we are having a working lunch of sorts
<cferris> people are grabbing pizza
<danroth> William: Read through the Primer as a newbie
<danroth> will: Section 2.2 contains first example
<danroth> will: Explains why you would do a policy for SOAP messages
<danroth> will: Example doesn't show how to attach the policy
<danroth> will: We could show an example or add a forward ref
<danroth> will: Example should show policy inline, not by ref
<danroth> glen: We could just use the attachment example to show the policy. Bold the policy
<danroth> will: We always show references. We don't show inline
<danroth> will: We should layer the complexity like candy
<danroth> dan: We should be sure to be consistent with our recommendation to use PolicyReferences instead of inlining
<danroth> umit: I have seen both inlining and references in the wild
<danroth> chris: let's get a concrete proposal
<danroth> will: There are two issues because they affect different parts of the Primer
<danroth> chis: we can show the example with the policy inlined and then forward reference
<danroth> chris: there is general agreement to flesh out the example with WSDL attachment
<danroth> chris: the difference of opinion is if it is inlined or referenced
<danroth> ACTION: william and daniel to flesh out the concrete proposal [recorded in http://www.w3.org/2007/01/18-ws-policy-minutes.html#action01]
<trackbot> Created ACTION-200 - And daniel to flesh out the concrete proposal [on William Henry - due 2007-01-25].
<danroth> ACTION: william to create a concrete proposal for 4255 [recorded in http://www.w3.org/2007/01/18-ws-policy-minutes.html#action02]
<trackbot> Created ACTION-201 - Create a concrete proposal for 4255 [on William Henry - due 2007-01-25].
<danroth> maryann: SX TC didn't meet for four weeks (Dec 9 through Jan 9) and didn't meet again until Jan 9
<danroth> maryann: This is why the notifications to review were not processed
<danroth> asir: Paul has been contacting chairs offline
<danroth> symon: SX is not meeting next week. They are now meeting every other week
<danroth> frederick: if we have to have CR by March 1?
<danroth> chris: It's by March, not March 1
<danroth> frederick: Why do we need CR by January?
<danroth> chris: it takes two weeks between transition request and publishing
<danroth> chris: we need to prepare the request
<danroth> chris: does the working group want to make the transition request?
<danroth> asir: no one is asking for additional LC time
<danroth> asir: people are asking for 2 weeks to review the editors draft
<danroth> asir: decision could then happen at Feb 7 call
<danroth> asir: SX should start reviewing now
<danroth> asir: ok with Feb 7 decision
<danroth> felix: The SX TC hasn't expressed what Tony is saying
<danroth> felix: Would it be possible to get a mail from SX within the next week?
<danroth> ACTION: chris to followup with the SX TC if they are requesting additional time to do LC review for policy [recorded in http://www.w3.org/2007/01/18-ws-policy-minutes.html#action03]
<trackbot> Created ACTION-202 - Followup with the SX TC if they are requesting additional time to do LC review for policy [on Christopher Ferris - due 2007-01-25].
<danroth> asir: We have responses from addressing, TX, RX . . .
<danroth> asir: All dependencies identified in our charter have responded other than SX
<danroth> umit: concerned that editors won't be done by Weds
<danroth> umi: proposes end of next week
<danroth> frederick: I will be unavailable
<danroth> asir: we have a big editorial team
<danroth> asir: the team is big so that we can substitute for each other
<danroth> umit: we need to decide the timeline as an editorial team
<danroth> felix: we have until March 31 to get to CR
<danroth> chris: hearing that one week is not enough time to review all edits
<danroth> chris: group is requesting 2 wks
<danroth> chris: also hearing through Tony that SX has not been aware of the request to review
<asir> +1 to allow 2 weeks for reviewing the edits (that includes decisions until this F2F
<danroth> frederick: it is not clear how effectively the addressing group is reviewing effectively
<danroth> tom: give feedback to them
<danroth> maryann: wants to use addressing as an example in the guidelines doc
<danroth> maryann: can't understand addressing as an example
<danroth> chris: hearing that we should differ until Feb 7
<danroth> 10 min break, resume with primer and guidelines issues
<danroth> chris: asir sent a feature list
<fsasaki> scribe: danroth
chris: we need volunteers to fill
in the gaps with interop tests
... xml:id policy identification
asir: a note on Round 1 and Round
2 test cases
... these are unit tests for normalization and intersection
... Paul mentioned completing up through Round 3 testing for March
... Round 4 can happen afterwards
umit: is there a repository for
... like ws-addressing tests?
chris: we will determine ownership first
felix: I agree to submit to CVS,
but not create a test suite
... I can look into what addressing does
chris: no one volunteered to
create tests for UDDI attachment. The feature is probably at
... no one volunteered for URI domain expression scenarios. Might also be at risk
<scribe> ACTION: fsasaki will create test cases for xml:id [recorded in http://www.w3.org/2007/01/18-ws-policy-minutes.html#action04]
<trackbot> Created ACTION-203 - Will create test cases for xml:id [on Felix Sasaki - due 2007-01-25].
<scribe> ACTION: cferris will create test cases for xml:base [recorded in http://www.w3.org/2007/01/18-ws-policy-minutes.html#action05]
<trackbot> Created ACTION-204 - Will create test cases for xml:base [on Christopher Ferris - due 2007-01-25].
<scribe> ACTION: glendaniels will create test cases for the policy MIME type [recorded in http://www.w3.org/2007/01/18-ws-policy-minutes.html#action06]
<trackbot> Sorry, couldn't find user - glendaniels
chris: these actions are due by next call
chris: action 152 has been done be daveo for a while now
dorchard: proposal review:
existing versioning scenarios do not need wsp:Ignorable
... could use wsp:Ignorable with an EndOfLife assertion for doing side-by-side versioning
dan: concerned that the assertion is ficticious. Are we really ok with recommending that people use this assertion?
glen: disagrees that there is any
... WSDL primer uses ficticious examples
... it's ok for strict mode clients to fail
dorchard: this proposal is about versioning
<FrederickH> glen pionts out that example assertoins do not need to be fully defined
dorchard: open to a revision to an example versioning assertion
dorchad: wants to see an example of a versioning assertion
<Zakim> asir, you wanted to provide a counter to Glen
<FrederickH> +1 to glen and david, need example in primer of ignorable
<umit> can't we use the words that the assertion example is just illustrative and it is not provided to endorse a specific semantics or recommend it...
<FrederickH> +1 to umit
<FrederickH> Agree with Asir that need to ensure fictitous example is not treated as normative or a correct outline of how to create a real assertion
asir: breaking existing clients using strict mode doesn't seem ok
dorchard: ignorable assertions always break strict mode clients
dan: we could say that the example targets lax mode clients
monica: we should capture the usage rules that we discuss and get them into the primer and guidelines
cferris: we need an issue for this
glen: we might want guidelines that explain that using strict mode implies that you might fail in a variety of circumstances where truly "sideband" information is marked ignorable
cferris: are people comfortable with adding dave's proposal?
asir: we also want the strict vs lax issue addressed
<scribe> ACTION: dorchard to open an issue for action 152 with the existing proposal [recorded in http://www.w3.org/2007/01/18-ws-policy-minutes.html#action07]
<trackbot> Created ACTION-205 - Open an issue for action 152 with the existing proposal [on David Orchard - due 2007-01-25].
cferris: for issue 4041, let's go with the latest revision in message 187
frederick: domain specific
processing should be able to know if an assertion is
... Let's only accept the editorial revisions and open an issue for the rest
cferris: Let's deal with the domain specific processing of ignorable assertions separately
frederick: how normalization deals with wsp:Ignorable attribute should stay in the proposal
dan: agreed. It's actually not removed, I suggested moving it from the intersection section to the Ignorable attribute section
glen: is fine with accepting the proposal as long as we can raise future issues against it
<asir> ACTION: Frederick to open an issue to address the deleted paragraph in the proposal from Dan for issue 4041 (see thread 187) [recorded in http://www.w3.org/2007/01/18-ws-policy-minutes.html#action09]
<trackbot> Created ACTION-206 - Open an issue to address the deleted paragraph in the proposal from Dan for issue 4041 (see thread 187) [on Frederick Hirsch - due 2007-01-25].
RESOLUTION: Resolve 4041 with the proposal in mail 187
chris: Asir, what is the status
of action 183?
... Fabian expressed concern that Contoso was trademarked
asir: I am still doing my homework. Will have this for next con call
chris: Umit, tell us about the new primer issue on emptly policy for nesting
umit: this is related to the resolution for 4142
chris: SX is concerned about this
maryann: Tony is concerned that
an empty nested policy element should be a wildcard
... also, in interop we only test the behavior exchange
chris: the chair sees no one opposed to publishing the WSDL 1.1 EI doc?
RESOLUTION: Seek public working draft of the WSDL 1.1 EI doc
<scribe> ACTION: fsasaki to get the WSDL 1.1 EI doc published [recorded in http://www.w3.org/2007/01/18-ws-policy-minutes.html#action10]
<trackbot> Created ACTION-207 - Get the WSDL 1.1 EI doc published [on Felix Sasaki - due 2007-01-25].
<scribe> ACTION: cferris to put together status section for the pub of the WSDL 1.1 EI doc [recorded in http://www.w3.org/2007/01/18-ws-policy-minutes.html#action11]
<trackbot> Created ACTION-208 - Put together status section for the pub of the WSDL 1.1 EI doc [on Christopher Ferris - due 2007-01-25].
chris: read new proposal for issue 3986
monica: is the best practice only for default intersection?
dan: it's actually relevant to intersection in general. It's best practice to not require domain specific processing
asir: this proposal also resolves 3985
... 3985 was about expressing what parameters are in the guidelines doc
tom: this is the first time that
I've seen that domain specific intersection uses assertion
... is there any other way?
dan: you can do whatever you want in domain specific intersection
tom: this seems like a normative statement
dan: there is normative text in the framework as well
monica: we should say "default interection"
dan: default intersection is not defined in the framework
chris: maybe say "domain specific compatibility processing"
RESOLUTION: Accept the proposal in message 191 for resolving issue 3985 and 3986 with Chris's ammendment above
monica: my action to open an issue related to 4206 may be resolved by thi proposal
cferris: thanks to everyone who participated
cferri: thanks to BEA for hosting
cferris: Please review the
editors drafts earlier rather than later
... The chairs need the time to gather the materials for CR request
asir: WSDL 1.1 EI needs to be published before or with the specs
fsasaki: It will be published next week
cferris: safe trip home everyone!
fsasaki: thanks the chairs and everyone for their great work and keeping it cool