See also: IRC log
<trackbot> Date: 04 May 2010
Hello, Dave the scribe
<Bob> scribenick: DaveS
Agenda Approved.
Minutes approved.
Topic New Issues
<Dug_> and: http://www.w3.org/Bugs/Public/show_bug.cgi?id=9655
9607 - 9613 Accepted as New issues
9655 accepted as a new issue
9588 accepted as a new issue
<Dug_> +1 to proposal for 9588
RESOLUTION: 9588 Resolved as proposed.
Fred Joined.
<Dug_> breakfast?
Start each day at 9:00 (Ram will let people in from 8:00)
Breakfast will be provided.
<Dug_> woo hoo!
Topic Next F2F
Proposal from Bob to leave it open.
To be discussed at the F2F. Expected to be inline with the normal 6 to 8 weeks cadence.
<Dug_> I'd prefer if the next f2f were an interop
F2F meeting discussion time will be announced in time for EU people to make sure they can dial in
Gil is working on a new approach to this issue.
Should be no problem for the F2F.
There seems to be little discussion on this one.
May be due to discussion on other issues.
Proposal from Doug to limit the scope of a resource
<Dug_> Latest note on this: http://lists.w3.org/Archives/Public/public-ws-resource-access/2010May/0005.html
Bob (the proposer) is mostly OK with it.
A friendly ammendnent that UTF both modes 8 and 16 also be supported.
The XML 1.0 spec states that 8 and 16 are required.
Doug's proposal states that the 8 and 16 issues is applied to all specs.
<Yves> it's already there by reference to XML 1.0, duplicating XML 1.0 spec using a MUST is not good
There is a difference between sender and receiver in the UFT encoding question.
XML 1.0 specifies that it must be supported, but there are other parts of the system that also need to comply.
Tom: Receiver MUST accept both.
Sender may typically send either and the receiver must understand both.
Gil: This it really only a problem with fragment, since the normal transfer puts the whole thing.
<Yves> you may require a specific encoding using ws-policy, but the policy is not defined for that, yet.
Bob: But what if the 16 version come in a GET to a clinet that would rather have 8 only.
<Dug> I'm lost as to the current proposal
<Dug> it sounds a bit like everyone is agreeing and yet the conversation still goes on ....
daveS: Agrees with Dug.
<Ram> Implementations are expected to support both UTF-8 and UTF-16 as described in XML 1.0.
<Dug> in compliance section for all specs
<Tom_Rutt> a client implementation may take the get response, in utf-16, parse it into a dom tree, and when they send it back the dom tree will be encoded in utf-8. The sending is an implementation specific matter
proposal:In addition to the restriction as to the resource types from XML infoSet add a note the the specs that implementations must support 8 and 16 as described in XML 1.0.
Tom: it is only the receiver that
matters.
... Both schemes will handle both.
Please satisfy the 3 Japanese guys in a bar in Kawasaki.
Agreed.
RESOLUTION: 9087 resolved as proposed.
The issue includes a sketch of a proposal.
This may be specific to frag only.
The content of the Frag spec would define the subset in question.
XPath Level 1 is a lightweight subset
<Tom_Rutt> q
This provides at least two levels of support in support of small servers.
The important issue here is that the server is the small light weight device in this case.
E.g. a lightbulb.
<Dug> eeekkk a lightbulb supporting soap! scary!
Gil: WS Man is concerned that Level 2 needs supported.
Maybe they shouldn't be lumped together.
But the use cases are distinct.
Tom: WS Man can do this them selves in their spec.
Level 1 is liked by a number of other uses.
The security request has a few comparisons.
The differences are minimual.
Ram: There seems to be some interest in having these subsets (unchanged) moved into a separate spec.
This would consolidate the number of document that subset XML.
Ash: Multiple dialects are a bad idea.
It may be handy to put the Level 1 spec in a separate document.
<Bob> http://www.w3.org/2008/xmlsec/Drafts/proposals/xpath-profile-levels.html
Tom: Level 1 in a separate spec is OK. Or is there another cahnge being proposed.
We need to at least answer the group.
From Section 3 of the proposal:
Create a separate XPath profile with WS-Fragment Level 1 profile (unchanged), XML Signature 2.0 XPath profile, renamed as Level 2 and material in section 7 ("XPath 1.0 Expression Language") of WS-Fragment.
Bob: These look definitly
different.
... Is it a good idea to have fewer dialects?
There is general support for having only one dialect and therefore maybe we should try theirs.
It would probably need to be in a separate spec.
Tom: The functions they include look pretty useful.
Asjh: We mostly have full implementations. It is sometimes more dificult to take stuf out.
Tom: these extensions are easy to implement and help the user a lot.
Ram: Who in this group would test this set of features?
Bob: Is Level 1 at risk anyway?
Doug: But if full support exists, we get the subset for free. The concern is with oour schedule.
Tom: Who are the customers?
Bob: We could close with no action, as this is mostly about spec efficiency.
<Tom_Rutt> q
<Tom_Rutt> =
<Tom_Rutt> q
Tom: The functions actually look handy. Maybe we should look at these.
Bob: One possility is close with no
action.
... How do we test this?
Tom: We build a test that tests only Level 1.
<Tom_Rutt> test cases could only exercise level one constructs
Then we also test full XPath as well.
Tom: The aim is to allow receivers to implement simple subsets. and it is easy to test.
What is the impact on schedule?
Gill: is breaking up.
Gill said it could help schedule, but we still need to hear why.
Proposal: drop Level one from us and say look at the other spec for subsets.
<Tom_Rutt> q
This implies keeping the QName only and Full XPath.
Ram: Take the path of least resistance.
There are some concerns with how to addres this testing of these.
Option 1) Close no action
<Tom_Rutt> what would our conformance test use for xpath elements,
<Tom_Rutt> just the xpath 1 subset?
Option 2) We like your subset, please put it some where we can teverence it
Option 3) Make out level match theirs.
Option 4) Give them our level 1
Option 5) Our spec says nothing and other specs can define what ever they want.
Number 5 leaves QName.
<Tom_Rutt> additional: if use option 5 we have to decide how complicated our test cases will exercise xpaty
In 5 we don't need to reference other specs.
In 4 we would reference another doc.
Dave and Tom like 5, but Tom's worried about testing.
Bob: Test Qname and an example of XPath.
The test only verifies that XPath is there. It is up to XPath compliance to cover the full XPath support.
We can stll say that the security guys could have Level one. And then possibly include a non-normative reference to their work if they finished first.
People should think about this over the next week.
Pause while people think.
This means that no delivery mechanism is required.
Sounds like more time is needed.
Thank you all have a good time next week.
Bye