Web Services Resource Access Working Group Teleconference -- 04 May 2010

<trackbot> Date: 04 May 2010

Hello, Dave the scribe

<Bob> scribenick: DaveS

<Dug_> someone is pounding hard on their keyboard

<scribe> Scribe: 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

Resolved 9588 Resolved as proposed.

Topic F2F Meeting

Fred Joined.

<Dug_> breakfast?

Start each day at 9:00 (Ram will let people in from 8:00)

<Dug_> phew! :-)

Breakfast will be provided.

<Dug_> woo hoo!

Topic Next F2F

<Dug_> ram will FedEX it :-)

<asoldano> ;)

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

Topic 9567

Gil is working on a new approach to this issue.

Should be no problem for the F2F.

Topic 9568

There seems to be little discussion on this one.

May be due to discussion on other issues.

Topic 9087

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: 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.

Resolved as proposed.

<Dug> Guess we don't care about gals in those bars

Topic 9558

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!

We lost Gill.

Gil is back.

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.

Topic 9655

Paus whail people think.

s/paus whail/pause while/

This means that no delivery mechanism is required.

Sounds like more time is needed.

Thank you all have a good time next week.

Bye

- DRAFT -

Web Services Resource Access Working Group Teleconference

04 May 2010

Attendees

Contents

Summary of Action Items

Scribe.perl diagnostic output