See also: IRC log
<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> 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
RESOLUTION: minutes approved
Jonathan: (runs through action items faster than I can type)
3. Review of Action items [.1].
[Interop]
DONE [.3] 2006-06-08: [interop] Arthur to create a testcase for
an unknown extension wsdl:required=true.
DONE [.3] 2006-06-08: [interop] Arthur to create a testcase for
an unknown extension wsdl:required=false.
? 2006-07-06: [interop] Jonathan - create validation-report
stylesheet.
? 2006-07-07: [interop] John to write spec text for transfer
coding
DONE [.4] 2006-07-07: [interop] Arthur to include counts of good/bad
documents in document coverage report
WG
? 2005-07-21: Pauld to write a proposal for a working group
report for requirements for schema evolution
following closure of LC124
? 2006-03-30: Marsh to make XSLT improvements for RDF
publication.
DONE [.5, .6] 2006-06-15: Arthur to update CR022 proposal.
DONE [.7] 2006-06-15: Arthur to propose part 1 text about REQUIRED
extensions.
? 2006-06-29: Philippe to write up recommended text to clarify
the issue in CR53.
? 2006-07-06: Glen to contribute some extension test cases.
? 2006-07-06: John to write proposal for CR055 based on
discussion and Jacek's email.
? 2006-07-13: Roberto to produce an updated proposal for CR044.
Current Editorial Action Items
- none -
Note: Editorial AIs associated with LC issues recorded at [.2].
[.1] http://www.w3.org/2002/ws/desc/#actions
[.2] http://www.w3.org/2002/ws/desc/5/cr-issues/actions_owner.html
[.3] http://lists.w3.org/Archives/Public/www-ws-desc/2006Jul/0065.html
[.4] http://lists.w3.org/Archives/Member/w3c-ws-desc/2006Jul/0009.html
[.5] http://lists.w3.org/Archives/Public/www-ws-desc/2006Jul/0079.html
[.6] http://lists.w3.org/Archives/Public/www-ws-desc/2006Jul/0080.html
[.7] http://lists.w3.org/Archives/Public/www-ws-desc/2006Jul/0076.html
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
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.
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.
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".
Roberto: Nothing for the group at this time.
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}"
<Arthur> scheme is standard, e.g. http://en.wikipedia.org/wiki/Basic_authentication_scheme
RESOLUTION: close CR060; rename "{authenticationType}" to "{authenticationScheme}"
<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