WS Description WG -- 20 Jul 2006

<Jonathan> hi

<Arthur> http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/test-suite/test-suite-coverage-summary.xml?content-type=text/xml

<Jonathan> ACTION: Jonathan to add timestamps to result stylesheet [recorded in http://www.w3.org/2006/07/20-ws-desc-minutes.html#action01]

<Jonathan> http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/test-suite/results/Overview.html

<Jonathan> ACTION: Somebody to create baseline for SparqlQuery [recorded in http://www.w3.org/2006/07/20-ws-desc-minutes.html#action02]

<Jonathan> Arthur, where is an example of the timestamp ant task?

<Arthur> Jonathan, for <tstamp/> example see http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/test-suite/build-test-coverage.xml?rev=1.2&content-type=text/plain

<scribe> scribe: Gil

approval of minutes

RESOLUTION: minutes approved

action items

Jonathan: (runs through action items faster than I can type)

administrivia

Jonathan: should cancel next weeks telcon

RESOLUTION: July 27th will be canceled

Implementers call will be suspended until people indicate that it will be held

Jonathan: next concall for this group will be September 7th
... SPARQL WSDL bug; haven't heard anything

CR76

Tony: Is CR76 covered by the work Arthur did on required extensions?

Jonathan: Not completely, but somewhat

Jonthan: My proposal was to make {rpc signature} property optional

Arthure: You can say something is required but qualify that with co-occurence constraints

Jonathan: I agree, but exactly what are those conditions?

Arthur: In theory we can have everything be optional

Glen: Great idea!
... The whole idea of required and optional properties is problematic.

Arthur: We have to talk about the component model independent of the markup.

Glen: The extension spec is going to cover both the markup and the component model.

Arthur & GLen: (back and forth on this topic)

Glen: All of this results from the confused way in which we explain required and optional.

Jonathan: Have we blessed the text on this?

Arthur: No.

<Arthur> here is the proposed text for a REQUIRED extension property

<Arthur> http://lists.w3.org/Archives/Public/www-ws-desc/2006Jul/0076.html

Glen: Its difficult to discuss the component model when extensions are engaged?

Arthur: Right.

Proposed Part 1 Text for REQUIRED Extension Properties

Glen: The component model really exists as an abstract model for us and extension writers to agree on semantics. Once you introduce the interchange format you start to veer towards implementation.

Jonathan: I understand your point, but the interchange format is a testable artifact.

Glen: Its ok to test the interchange format, but you don't need to reflect these constraints on the Part 1 document.

Jonathan: If you're going to use that abstraction I don't see the harm in surfacing it in the spec.

Glen: Ok

Jonathan: CR76 isn't really about the larger issue.

Glen: We already have a pretty complicated specification. If you're not up on the history this might be pretty hard to understand. But I agree that we should make this crisper.

Jonathan: Do we want to add Arthur's proposed text to Part 1?

Arthur: I do. I don't think this is just an interchange format thing. It's about reducing the ambiguity in the spec.

Arthur & Glen: (back and forth on what it means when a "required" property is not present)

Arthur: The thing that triggered this was the {safety} property. It is a required property but the markup was optional.

Glen: The "component model building step" is abstract, but you have to do it in a particular way and I'm not comfortable with that.

Tony: The presence or absence of an extension is important to judging the validity of a component model. We seem to agree on this.

Glen: True.

Jonathan: Are there improvements we can make to Arthur's text or do we want a broader solution?

Glen: I'm not ready to address the broader issue.

Who's speaking?

Roberto: Isn't it strange to define an extended component model?

Arthur: You need to consider the effective extensions when judging the validity of the component model?

Arthur, Glen, Roberto: (discussion on the meaning of "the component model" vs. "the instance document")

Jonathan: Is anyone proposing text different from what Arthur has proposed?

Arthur: The model is a set of components and the specification describes the possible set of components.

Glen: (detailed suggestions on Arthur's proposal)

<asir> Hi Jonathan, I joined the call 5 minutes ago

<scribe> ACTION: Arthur to update "Proposed Part 1 Text for REQUIRED Extension Properties" [recorded in http://www.w3.org/2006/07/20-ws-desc-minutes.html#action03]

Glen: "Requiredness" is defined but the set of extensions that are in play.

Arthur: That is using "required" in a way that is different from the way we use it in Part 1.
... The co-occurence constraints put a different twist on things.

Jonathan: "Required" means you can count on it being there but optional extensions are slightly weaker.

Jonathan and Glen: When you write an extension and you say something is required it has to be there when the extension is used.

Arthur: "Required" is a useful construct but we need use it in a consitent way.

Glen: Sure, but you can't say something is "optional" and then say it always has to be there.
... Proposal is to pull 6.4.1 out.

Arthur: Then we need to get rid of the "required" keyword altogether.
... There are problems with the way we use "required" in Part 2.

Glen: Revised proposal is to strike all but the first sentence of 6.4.1.

Arthur: The SOAP binding says you can use properties that are required in the HTTP spec.

Arthur and Glen: (back and forth on SOAP binding and HTTP properties)

Jonathan: I think this is covered by the first sentence of 6.4.1

Arthur and Glen: (more on "requiredness")

Jonathan: Are we converging on a solution?

Arthur: You need to change Part 2 no matter what.
... (cites examples of missing co-occurence constraints)

Jonathan: These examples are already covered by issues.

Arthur: If you fix Part 2, then we can focus on whether we want people to write extension spes with this "required" keyword.
... You need to spell out that such authors need to be aware of co-occurence constraints.
... Two options: rip out "required" and "optional" from Part 2 and spell out everything explicitly.
... Or leave this text in and modification via co-constraints.
... Its important that we do it right in Part 2 because others will use this as a template for writing their extension specs.

Jonathan: Of those two choices, I'd rather not rip out all the "required" and "optional".

Tony: (agrees)

Jonathan: Can we leave 6.4.1 alone (put in as is)?

Glen: Sure.

Jonathan: We'll revisit this on our next call.

CR76

Jonathan: Proposal is to add a co-occurence constraint between RPC style and {rpc signature}

Arthur: Clearer to say that this is an optional property that must be there if the style is RPC.

RESOLUTION: close CR76 : Add the co-occurence constraint and change language to "optional".

CR44

Roberto: Nothing for the group at this time.

CR058

Jonathan: There is a proposal to change the name of the {safety} property to {safe}

Tony: "safety" is not a good choice of names.

Joathan: "safety_asserted", "explicitly_safe" and "safety" is the status quo.

Arthur: Our XML markup is just "safe".

Jonathan: (reads proposal)

Arthur: I agree. We already call the XML attribute "safe". Why use two words?

Jonathan: Looking forward to next issue I note that the {authentication type} property doesn't match the markup. Is there a bigger issue around mapping property names to their markup?

All: (general agreement that attribute names should match the property names)

<Arthur> let's pick the best term for both the XML attribute and the component model property

<Arthur> i.e. just one term

Tony: "safe" is a technical term that is used the same way in HTTP land; we are as inaccurate as another spec.
... This use of the word is already used elsewhere in the same way. We can always point the finger at them.

Who just spoke?

<Arthur> http://www.w3.org/TR/2004/REC-webarch-20041215/#safe-interaction

<Arthur> that was me

Jonathan: Looks like we agree to renaming "safety}" to "{safe}"

RESOLUTION: close CR058 by renaming "{safety}" to "{safe}"

CR060

<Arthur> scheme is standard, e.g. http://en.wikipedia.org/wiki/Basic_authentication_scheme

RESOLUTION: close CR060; rename "{authenticationType}" to "{authenticationScheme}"

CR022

<Arthur> http://lists.w3.org/Archives/Public/www-ws-desc/2006Jul/0079.html for CR022a

Arthur: Any extension should produce the same result regardless of how you import.

Glen: You want to disallow somebody from saying that an extension is active in some outer document?

Arthur: An extension is active regardless of markup.

Jonathan: We don't know of any extensions that would violate this restriction.

Glen: Why do we need to say this?

Arthur: Performance reasons.
... (example of an include that says "append the word 'Glen' to every QName")

Arthur and Glen: (back and forth on what this restriction does)

Roberto: The example is one in which an extension is triggered by the import/include of a specific document.
... An extension which changes the components should appear at the top-level.

Arthur: Lets say you had an extension which was parameterized. You'd have to put that in each document.

Roberto: Seems like a bit much. I would hope there could be some scoping to handle this.

Glen: Agrees

Arthur: Why should something that's referencing a particular document be allowed to modify the components?

Glen: For import they shouldn't change but what about include?

Arthur: Include as well. The meaning of the components that get included shouldn't change depending on the way they are included.
... Import and include are component-level opertions. We want to know the meaning of those components independently of the way in which those components are pulled into a description.
... (specifics of the performance problems caused by not doing things this way)

Jonathan: Analgous to a compile step and a linking step.

Roberto: I agree that this is important.
... To do it right, wouldn't you need to move from a notion of a single component model to a model in which the component model is aggregated?

Glen: Right. How else would you validate?

Roberto: To follow the analogy of the Java packaging system, imports are handled locally to a compilation unit.

Arthur: You should be able to read each file once and build the components described by that file.
... When you check the validity of a specific root document you have to pull them together at that time.
... In the absence of this you end up reading the document multiple times. And then they refer to each other.
... Processing time should be roughly linear.

Arthur and Roberto: (riff on Java analogy)

Arthur: There are additional checks that need to be run after you pull the components together, but you should be able to do most of the processing up front.

Roberto: (specific suggestions to proposal)
... This is an improvement on the status quo.

Glen: (example of a management extension that extends every other interface in the description)

Arthur: Need to declare this extension up-front. Can't enable it via the include/import of another document.

Jonthan: Extension is enabled via markup.

Glen: Every interface gets extended this way. I don't care how the interface is declared, imported, or included it needs to be extended the same way.

Arthur: You shouldn't do it that way.

Glen: (agrees)

Arthur: You can't modify a Java class that you imort

Jonathan: Are we prepared to accept Arthur's proposal for CR022a?

<GlenD> I didn't exactly agree you shouldn't do it that way, I said yes there were other ways you could do it

- DRAFT -

WS Description WG

20 Jul 2006

Attendees

Contents

approval of minutes

action items

administrivia

CR76

Proposed Part 1 Text for REQUIRED Extension Properties

CR76

CR44

CR058

CR060

CR022

Summary of Action Items

Scribe.perl diagnostic output