See also: IRC log
<ericP> scribenick: EricP
<scribe> scribe: EricP
upcoming scribes: Joel (Tue pm), Rama (Wed am), will ask Laurent about Wed pm
<scribe> ACTION: Terry to review last call of WSDL RDF mapping http://www.w3.org/TR/wsdl20-rdf/ by beginning of July [CONTINUED] [recorded in http://www.w3.org/2002/ws/sawsdl/minutes/20060620#action01]
<scribe> ACTION: EricP to review last call of WSDL RDF mapping http://www.w3.org/TR/wsdl20-rdf/ by beginning of July [CONTINUED] [recorded in http://www.w3.org/2002/ws/sawsdl/minutes/20060620#action02]
<scribe> ACTION: Examples document editors to add "best practices" section, and to add the firstName/lastName scenario description [DONE] [recorded in http://www.w3.org/2002/ws/sawsdl/minutes/20060620#action03]
Lunch in the Westwood House Hotel [thanks to Deri]
Dinner at the Spanish Arch at 20:30 [self-funded]
Amit: for f2f scheduling agendum, consider the ISWC meeting in Georgia
<Amit> As for the mapping, the following paper accepted for ICWS may be of interest: http://lsdis.cs.uga.edu/library/download/techRep2-15-06.pdf
Rama: Some of us have jet lag and dinner earlier could be kinder
Brahmananda: the Spanish Arches starts serving dinner at 20:30
Joel: I encourage people to inspect our formal definitions and the use of 2119 MUST/SHOULD
Jacek: MUST often overused. example: attribute x MUST be spelled "x".
Rama: semantics defines words and their relationships. ultimately people interpret these words
An agent invoking a web service concearns itself with the semantics of the service, as well as its input and output messages.
<JacekK> ACTION: Amit and Rama (and anybody interested) to suggest definition of semantics [recorded in http://www.w3.org/2002/ws/sawsdl/minutes/20060620#action04]
suggestion: " semantic annotation is additional information in a document that
... identifies or defines the semantics of a part of that document. In SAWSDL, the
... semantic annotations are XML attributes added to a WSDL or associated XML Schema
... document. They establish the meaning of elements in WSDL document by
... referring to a part of a semantic model."
JacekK: can we eliminate Input Semantics and Output Semantics?
<Amit> Semantics of an object or information is its interperetation that can be defined with reference to the semantic model.
Amit: [above text] as advice on defn of Semantics
<JacekK> ACTION: ericP to use Amazon WSDL as a real concrete example [recorded in http://www.w3.org/2002/ws/sawsdl/minutes/20060620#action05]
Rama: does bookbuyer example include complexTypes
Holger: this example as all the types we need. does not have a re-used complex type
EricP: are our "constructs" really "components"?
Holger: these do not correspond to WSDL 2.0 components
style decision: acronyms pluralized with no apostrophes: URIs
Jacek: s/however it SHOULD be used especially for/this spec describes how it can be used for/
suggestion: [[
... The semantic annotation mechanism defined by this specification does not rely on
... any particular semantic modeling language. It only requires that the semantic
... concepts defined in it be identifiable via URI references. The URIs typically
... refer to a semantic model document external to the WSDL document. However, the
... URI's can also refer to elements within the WSDL document if semantic
... information is included in the document via WSDL extension elements.
... ]]
Jacek: "encourage that [it] be dereferencable"
[debate about semantic "concepts" or "entities"]
Jacek: we want two levels of TOC
John: can we eliminate distinction between leaf and upper level?
Amit: i think you can copy the ontology [into the spec space]
[discussion of better match candidates]
john: you would never use a rosettanet pip to buy from amazon
<JacekK> ACTION: Rama to try and come up with a better annotation for the subsection "Annotating operations with model references" [recorded in http://www.w3.org/2002/ws/sawsdl/minutes/20060620#action06]
John: [propose] an example of B2C and then an appendix of B2B
Rama: we had a terminology disconnect over "user" vs. "developer". spec needs to be clear about *who* will annotate [service descriptions]
claudio: b2c is very important for us
<JacekK> ACTION: Rama to send an email to open an issue on whether we target B2B or B2C [recorded in http://www.w3.org/2002/ws/sawsdl/minutes/20060620#action07]
Holger: add concept to the terms
Jacek: container-level annotation and child|member-level annotation
... Annotating Complex Types will describe the difference between annotating the memebers vs. annotting the container
... and difference between annotating an element vs. its type
2.2 should follow the changes of 2.1 modelReference (near "SHOULD")
[discussion of annotations on anonymous types and elements that use that type -- editors should note this]
<JacekK> ISSUE: precedence rules for schema mapping annotation
Joel: I don't think we have a clear example of something that would get mapped. perhaps name or address
<JacekK> ISSUE: revisit section on WSDL 1.1 mapping after the main parts of the spec are done
Jacek: we will need to revisit section 3 after we have finished section 2
... what he said
Holger: am optimistic that WSDL2.0 will be implemented, but not sure it will be done before we are done
[discussion of CR exit criteria]
Holger: i don't think we need to test inference
EricP: propose tests that select a matching operation based with matching input and output
Claudio: working with "parlay X" (SP?) web services
... asking them if they plan to migrate from 1.1 to 2.0
... currently, they say "no", so we have to play with 1.1
<JacekK> ACTION: team contacts to let the editors know about the standard reference style [recorded in http://www.w3.org/2002/ws/sawsdl/minutes/20060620#action08]
<JacekK> ISSUE: what is the relationship of interface annotations in face of WSDL 2 interface extension
<JacekK> ISSUE: do we need multiple schemaMapping values?
Joel: propose that you can add a schemaMapping every place in the schema where you can add a modelReference
RESOLUTION: schemaMapping may be added every place in a schema where modelReference is allowed
(note about the minutes - this resolution is overridden by resolution for issue 8 below)
EricP: we need multiple schemaMappings for the same reason we have multiple modelReferences
... could anyone make use of the distinction between all-apply and are-alternatives ?
<scribe> scribe: JoelF
<Joel> scribenick: Joel
John: Stay with simple case of schemaMappings being alternatives
Jacek: Same for Model References
Eric: For all apply because resonable for MR and no problem for schemaMapping
Jacek: Lifting could work with "all apply" but for lowering need to come up with a single XML message
... coming from one knowedge base to a single schema
Rama: can one mapping take output from another via an import, not specified on schemaMapping
... yes, doesn't require another URI
Carine: Mixing use cases, should address issue 7 first
Jacek: cases are 1 model, 2 models in same language, 2 models in different laguages, and combination of all
Rama: can have no modelReference and still have a schemaMapping
Amit: but without modelReference we have not semantics, so there is no point
Joel: If SM without MR, we must know what model to use
Jacek: Cases for mapping - none, single, two in same language, two in different languages
Laurent: last three cases for MR can be seen as the same use case
Amit: should not consider cases where there is no modelReference
Joel: keep the concepts clear, so even though schemaMapping references parts of the model, it is not an explicit statement of the semantic relationship
Jacek: there a cases where client already has semantic data but will not use it.
Laurent: schemaMapping can hide the model. Might be a use case.
Rama: schemaMapping won't get to invocation right away. Schema mapping is still at the semantic level.
... more work is needed to achieve invocation.
Jacek: different URIs are different models. Using two languages for the same model is not a separate use case.
... case no schema mapping is just discovery
... case two mapping laguages, one model - alternatives for invocation
... 2 mapping, one model - mapping to multiple modelling languages
... would need to run both mapping functions to see which works
Joel: note - the cases above are for when there is not explicit modelReference
Carine: not a useful case
Eric: from query perspective, it is useful
Laurent: questions if we need an ontology of mappings and maybe other elements so an sawsdl file can be understood
Jacek: need to look at efficiency of resolution to see what type of model is used
<caribouGWY> ISSUE: efficiency of resolving the type of model being referenced
Thomas: should make really clear is spec that it is independent of type of model and mapping function
Jacek: one mapping, one model - discovery. We need to support
Rama: don't need to distinguish between ontological schema and ontological data
Amit: might need to know the data
<ericP> caribou, created -> http://www.w3.org/2006/06/20-lift
<ericP> caribou, what should i clarify in this?
<ericP> (note, i just added a sentence at the bottom)
<caribouGWY> Eric, it looks like just data binding to RDF...
<ericP> caribou, it is. it's a candiate use case for liftingSchema
Jacek: can't define the relationship between mappings and model references
... from table looks like they are all alternatives - used to specify alternatives
PROPOSAL: Schema mapping on any schema element that are alternatives, model references all apply
... no other relationship
Rama: two services can have mappings to two parts of an ontology
... can client conclude anything about the relationship between the services?
... can lift from one and lower into the other
Jacek: we are not going to use mapping for discovery
... not having a model reference but having a schema mapping is ok and can be used for integration
Rama: can let you know that service can be used.
Eric: We should not eliminate the ability to compose to mappings
Jacek: But logically, it will not work.
Rama: associating model references with schema models is not needed
Jacek: can have liftingSchemaMapping without loweringSchemaMapping
RESOLUTION: schema mappings are alternatives, model references all apply, we do not specify any other relationship between them
issue 8 rephrased as "precedence rules for schema annotations"
Eric: move from outer to inner mappings on the complex type
... we could run them all, just like resolving alternatives
Jacek: propose that outer mapping precludes inner mapping
PROPOSAL: schemaMapping on outer scope precludes any found inside the scope
... For mappings whose scopes do not overlap, both apply.
Carine: maybe we should preclude any mapping on a leaf level
Rama: can outer be a incomplete mapping and the inner mapping completes it.
Jacek: Not possible for lowering
Laurent: not impossible, might be difficult, but possible.
John: can outer go to OWL and inner go to UML?
Jacek: hard to specify how this would be processed.
Carine: but burden is on creator of XSLT
Rama: Could have a predefined mapping that I want to use for a particular attribute
Jacek: should use xslt import. Also, don't know where to insert the result of the specific mapping
Eric: there is a way to change the XSD to address this.
Joel: but annotation should not require changing the schema.
Laurent: mapping on Complex type is a default that can be overridden
... want to reuse complex type - can we make the mapping global
Jacek: just extend the complex type
Eric: maybe put schema mapping on operation and appy to all
Joel: but stops us from writing simple mappings for specific simple cases.
Jacek: do not seem to be a way to specify how schemaMapping on an attribute
John: global elements, complex types and simple types can have schema mappings
Rama: We don't want to preclude mappings to different semantic models (languages)
Jacek: would be a problem in even with same languages
Rama: We should consider different modeling languages here also
Jacek: But that was not the deciding case for other decisions.
Laurent: Do we support cases while where we create a schema mapping for a sequence?
Jacek: We point to schemaMappings, we do not create them.
... allow schemaMappings anywhere, but describe it only in the places listed above
<JacekK> PROPOSAL: we describe only putting schemaMapping attributes on global element declarations, global simple and complex type definitions, and if schemaMapping is specified on the element declaration, it precludes the schemaMapping (if any) on the type of the element, and vice versa, if the element does not specify a schemaMapping, the schemaMapping of its type applies
Jacek: schemaMapping="" precludes the use of any schema mappings on its type.
... Proposal includes this case
Rama: can we enforce the preclusion rules in XML Schema? Will try to find the information on how it might be done.
Jacek: correction - schemaMapping="" precludes the use of any schema mappings FROM its type
RESOLUTION: we describe only putting schemaMapping attributes on global element declarations, global simple and complex type definitions, and if schemaMapping is specified on the element declaration (including empty value ""), it precludes the schemaMapping (if any) on the type of the element, and vice versa, if the element does not specify a schemaMapping, the schemaMapping of its type applies
Jacek: can only enforce rules in normative text in the specification
... Original Issue 8 obsolete due to text deleted because of other resolutions
... revised issue 8 applies to schemaMapping
<scribe> CLOSED Issue 8
<caribouGWY> Scribe: LaurentH
<caribouGWY> ScribeNick: laurenth
proposal: second f2f in Turin
proposal second f2f last week of august
<caribouGWY> proposed dates are August 29-30 (Tues-Wed)
proposal: third f2f in Georgia around the week of 6th november
carlos: would be better starting at the ninth november, spanning over the next weekend (saturday 11th)
RESOLUTION: Second f2f hosted by Telecom Italia in Turin, Italy, August 29-30 2006
jacekk proposes not to have august off for a vacation
JacekK cannot chair July the 18th, 25th, nor august the first, 8th
RESOLUTION: canceling telecons August 1 and 8
JacekK willing to publish the WD next week.
rama: question: do we need to have the examples document ready as well?
ericP, jacekK: not a problem.
jacekK: we may even have bugs in the WD, this is just a proof of work and progress
holger: we need an example with simple and "simple" complex types
... this is needed for section 2, with lifting and lowering, not in the attached examples document
ericP: would like to run through the spec at a telcon, and expect the category issue to be resolved
jacekK: two options: polish what we have already done, or put together all that was resolved at the expense of an ugly document
ericP to vote for second choice (including early category resolution)
carlos to vote for the polished side
joel: the WG should account for all that was decided at this meeting
... disagrees that we need the schema mapping examples running
rama: expects easy to understand explanations (what are the principles, and motivations, not only the rules)
... expects this in the first WD.
... reader shouldn't be requested to get through the axamples to understand
ericP: disagree - never seen any critics against a 'too rough' first WD
rama: would like to contribute
jacekK: ok to submit rewording, or become a third editor
rama: would like to get feedback from people about when the use cases document should be ready
jacekK: we do not have requirements 'contentwise' for the use cases document
JohnMiller: we can keep it rough because we cannot match a quck deadline
thomas: everything we put in the specs should be reflected in the use cases document - even for the working draft
... examples in the spec should be extracted from the use cases document
... a comment: would be interesting to have an external review
laurenth: document structure is most important to me
... contents can be pretty rough for the 1st WD
caribou: i think the use cases dod should not be published yet as we have not discussed it yet
... the status of the use cases document is unclear
... for the use cases document to be useful, we should concentrate on it, work on best practises, work on coverage of combinations
jacekK: a skeleton of use cases document could be useful
caribou: this is a useful discussion, but not a useful document to publish now
... we have to prove that what we offer cannot be achieved without semantics
rama: clarification question: status of the use cases document: normative or not?
caribou: would be a non normative document, as 'working group notes'. Very useful to have a primer that explains the spec
jacekK: can we have link from the WD to the editors copy?
caribou: no, because of link obsolescence
claudio: useful to review the TOC for section 2. Would appreciate a clear example in th WG as welll
bns: agrees with thomas, caribou, claudio
rama: one working example throughout the document
<bns> +1
jacekK: as polished as possible, one example, drop any example that would disagree with the main stream
john, rama, joel: about the appendix
joel: appendix could be a big B2B example
john: put things together and have a big example in the appendix
ericP: purchaseOrder and buyBook are pretty much the same complexity
rama: we should have only one example : no need to have different examples in the document and the appendix
jacekk: can people not read B2B?
rama: the buybook example is outdated in the business world
ericP: the first example must target the expected community
jacekK: editors: can we change that for the end of next week?
holger: no! single possibility is to rename the example
joel: possibility to add some fields to it, so that it looks more realistic
rama, everybody: remove 'book'. Better to have 'item'. Also replace 'purchase' with 'order'
jacekK: all the resolutions that we made are in rough form
... rename the example so that it is B2B like
... polish as possible
... finalize toc
... all four earlier elements are required for publication
... editors: when can this be achieved?
holger: end of the week
joel: mid next week
jacekK: if we have a draft next tuesday, we can discuss and approve it at the next telcon
... ready for 4th of july
ericP: see what is done on tuesday, and decide on a list of remaining elements
... and name a group of trustees to help the reviewing and prepare publishing
... editors should cvs commit by next monday evening
jacekK: ok for a cvs end of monday, american time, as the other american participants agree
claudio: objective is to show the group what we need from sawsdl
jacek: the slides presented will be made available
<JacekK> link to slides -> http://lists.w3.org/Archives/Public/www-archive/2006Jun/att-0028/TI_SAWSDL.zip
thomas: how does it fit with the ims?
claudio integration low level with cisco for efficiency
john: about QOS?
claudio: very important to us
... requirements on services: target category, supported protocols (SIP...), content type, service quality, service cost model
john: interested in realistic cost models. Do you have any?
claudio: not really
rama, claudio: the need is to attach annotations relevant with the cost model
rama: do you have a registry where all the discovery and composition queries could be read from?
claudio: we have research on extending uddi, and are working on a proprietary solution
rama: uddi is not used any more
john: so where is ibm going on this subject
claudio: we have requirements incompatible with uddi
john: do you have a mockup of the architecture?
claudio: not yet - this is within an ongoing project. we work with university of Milan and Trento, Pisa : Luciano Barresi, Marco Pistore, Ugo Montanari
thomas: should this use case become ours
jacekK: yes. Could the editors work on this?
rama: i'll take a look, need more information
thomas: we have a use case about the integration of SIP, VOIP and wS. We could start from this in the examples document.
jacekK: we have a proposed ontology for category
john: we can have an abstract provider type with attributes or relations to 'industry', 'product', 'location'
ericP: ok to drop category
joel: disagree: the motivation for category is to place in this placehoder information that could not be in any ontology
... to support the existing practise, we must have something
rama, holger: ok for this to be informative, not normative
rama: we have a modelReference, that points to a category
ericP: we have an example in owl, but the meaning for modelReferences in interfaces is to point to a description of what the service does
laurent: there may be a difference however, since at the interface level we are talking about instances
holger: a modelReference does not necessarily mean 'a class'. It means 'something'
rama: what is the problem with the category schema in the statusquo?
john: it is not semantic
holger: it not complete, and should remain open
<caribouGWY> +1 to the extensible model
jacekk: how do the properties in the proposed ontology map to the previous category attributes (as eg. taxonomyCode)
... why do we have the categoryName field? Just for documentation?
ericP: all you need in the documentation in WS is a pointer to the description
rama: we need two pieces of information: model and value
john: would like to keep the 'name'
jacekk: not happy with this
ericP: having a series of uris that describe our interfaceis ok. Finding a correlation between them is human job
... not machine job
joel: a problem is that the taxonomies are already there. We have to solve this
<holger> http://www.naics.com/censusfiles/ND443112.HTM
jacekk: taxonomies have a uri (as naics).
rama: we have to give room to provide as much information as possible
... not all services correspond to a single code
... users may want to provide additional metadata
ericP: the information could be either at the target location or inside the spec
john: our spec allows either approach
ericP: taxonomies, as ontologies will become arbitrarily complex
rama: instead of further speficication, go for a triple <name,ontology,value>
jacekk: to be more general and extensible, we can defer structure to the ontologies
... then we do not have to care for an extra extension point
rama: problem: people have their own classification to put things in their registries
... their descriptions are not necessarily available from the web
jacekk: can you give an example?
... private uris can be used as modelReferences
... value parameter is better than inserting in the uri
caribou: what if we have several values?
jacekK: code + value is fixed, and covers 80 percent of the cases
... the user can either use wsdl extensibility or place information in the ontology
... if we can come up with a limited number of fields, we can create the ontology from this. This is in scope.
rama: what is in scope?
jacekK: categorization for interfaces
caribou: nothing about categories, but requirement for interface annotation
jacekK: uri+code is enough
rama: vote for xml syntax
john: could do either one
proposal: drop the name, drop the value. rename to uri
jacekk: the code can be iun the uri, but may not
<ericP> http://mycompany.local/mytaxonomy#rfid-checkout
<caribouGWY> http://mycompany.local/mytaxonomy/mylittlescript?code=rfid-checkout
laurent: the code is maybe unnecessary as well
<holger> one could use http://www.unspsc.org/search.asp?CSS=%2552160000
ericP: a model referecne 'may appear' on the interface OR a modelReference 'describes' ...
<JacekK> ISSUE: what does modelReference on wsdl:interface mean?
<chad> Option 0: status quo (0)
<chad> Option 1: URI + code in XML (0)
<chad> Option 1a: URI + optional code (in XML) (1)
<chad> Option 2: modelReference (0)
<chad> Option 3: modelReference + our non-normative ontology with URI + code (11)
<chad> Option 4: modelReference + our normative ontology with URI + code (0)
jacekk: option 3 is informative, non normative
... option 2 model reference, no ontology
carlos: we might represent the ontology graphically: in abstract form
rama: disagree with 3 if it means providing an owl ontology
... think that the question here is not that much semantical
jacekK: the modelreference cannot point to xmlSchema. It must point to an xml document that describes the category
... we have an indication of preference for a model reference pointing to a category
RESOLUTION: category moved to modelReference, we will provide non-normative example ontology for capturing URI and code to point to a category
<caribouGWY> Scribe: RamaA
<caribouGWY> ScribeNick: rakkiraj
Laurent withdraws the issue
no action being taken
RESOLUTION: Issue 16 closed
Holger: We should specify everything from the root of the document
<JacekK> for lifting XSLT mapping, the input to the XSLT processor is the element on whose declaration the mapping is located; or an element valid according to the type on whose definition the mapping is located So, if it's on the type, the root element's name is unknown.
Joel: This description is normative.
<JacekK> for lifting XSLT mapping, the output of the XSLT processor will be semantic data for the client
<JacekK> for lowering XSLT mapping, the output of the XSLT processor will be the element on whose declaration the mapping is located; or an element valid according to the type on whose definition the mapping is located
<JacekK> for lowering XSLT mapping, the input will be some semantic data from the client
Joel: These statements are true regardless of the language.
Jacek: seconds that. We can drop the term XSLT in all these statements.
Issue 14: Second part.
Holger: If you have a comple type and you don't know the element name, what would be the input to the processor
Jacek: Clarification is that the name of the element is unknown.
... So, it will be addressed as /*/ in XSLT - for example
Laurent: We have to prove that this is viable with the existing technologies.
Joel: It doesn't have to be how ti works exactly but it has to describe how to interpret it.
... Put the text that Jacek created and use his examples.
... Even if these examples are not our standard example in the doc for working draft may be ok.
Jacek: Issue 14. Clarification. We will have generic text that applies to any mapping processor.
... And it will not be in appendix
RESOLUTION: Issue 14 - we will have normative generic text about the inputs and outputs of the schema mapping processors
Laurent: by having model References at interface level we can reference anything.
... I won't fight this
Joel: It's so much simpler when you are in XML schema trying to annotate. I prefer to keep it as an attribute.
... In the future we could introduce additional modelReferences but I don't see it now
Jacek: This is partly opened because of the possible relationship between modelReference and schemaMapping
... But given that yesterday we decided that we don't specify any relationship between modelReferences and schemaMapping, we may not have a reason to pursue this issue anymore
Laurent: There is no way to speak about modelReferences from the outside.
... But I'm not the right person to come up with a proposal for addressing this issue
Jacek: In the absence of a concrete proposal, we dont' have a reason to pursue this issue.
Carine: Want to be able to say something about the quality of the modelREferences
carlos: Do you want to reify modelReference?
... Perhaps we could postpone this until we are ready to address efficiency issues.
Jacek: Has the same feeling. Can leave the issue open issue still but not discuss it right now.
Laurent: If we don't have this, we may run into some problem to extend modelReferences. A URI cannot integrate data about what the user expects from it.
Jacek: Inclined to keep this open for a week. Wants someone to come up with a concrete proposal in a week
Laurent: What about the compatibility and interoperability
Jacek: Issue 21 is resolved with no action, may be reopened in light of new information.
RESOLUTION: issue 21 closed with no action
Jacek: This is superceded by our previous resolutions
... We have decided that we will have sections explaining the details.
RESOLUTION: issue 11 closed by being subsumed by previous resolutions
Jacek: It is editorial. It will be closed as soon as how they have resolved it.
Rama: The approach is to use the resolution to categorization topic to document the example.
Jacek: If the resolution is not editorial, editors will bring up the issues to the WG.
Jacek: needs to cleanup text
Joel: Wants to clean things up before publication
Jacek: issue will be reviewed later when the rest of the spec is finished
Jacek: If we address issue 20 and give specific examples relating to how UDDI taxonomy can be specified in a SAWSDL file, issue 19 would be addressed.
<JacekK> PROPOSAL: we can say that if a UDDI taxonomy URI is used to categorize a WSDL interface; it should be consistent with where the WSDL is filed within the UDDI registry; for example, when the WSDL is put into UDDI, the tModel could automatically have that categorization
Carine: where would this be in the spec?
Jacek: It could be in the section that talks about categorization
Carine: What's the right place? Section or the appendix?
Jacek: Section should point to the appendix.
Joel: Clarification on what CArine said and says it's better for this to be in the appendix
Laurent: Thinks the issue is more general.
Joel: We could say a few words about other registries as well
RESOLUTION: we will say that if a UDDI taxonomy URI is used to categorize a WSDL interface; it should be consistent with where the WSDL is filed within the UDDI registry; for example, when the WSDL is put into UDDI, the tModel could automatically have that categorization
Joel: It would be nice to describe a use case and see the examples that match that.
Jacek: the question at hand is: what is the purpose of this document?
... We should have best practices.
... The use cases can have happy-path examples and best practices section could contain the detailed corner cases where we want to illustrate that there is something non-obvious
Carine: Combine sections 2,3,4,5.
Claudio: Rename the categories to say something like 'using semantic annotations for discovery, for composition etc.'
Thomas: We don't need to go into the details but it should talk about why do you want to annotate a WSDL
Carine: No need to combine how the composition could happen.
Jacek: preferred option: Concrete examples, concrete small scenarios
... other options: 2. Big scenarios - big picture
... 3. Abstract categorization of what can be done with SAWSDL and how it can fit in there.
Thomas: May be useful to have Big picture scenarios also.
Jacek: It would be good to see actual text before we can determine if that would be of value.
... suggestion for reconstruction of TOC. Conflate 2-5.
... In the section, it says something like ' this shows how SASWSDL can be used to do discovery in the context of an item availability scenario'.
... Proposal: Conflate 2-5. In the section, it says something like ' this shows how SASWSDL can be used to do discovery in the context of an item availability scenario'.
... Proposal: Move section 6 as a subsection of best practices in section 7
... Call it Interface Mapping Scenario/Data mediation without XML Schema. You can see section XXX for dealing with instance data.
... Sprinkle the examples with excerpts of saWSDL annotations
Joel: This spec has more value that it gets credit for and we should make a case for it in the examples by talking about it.
Carine: We don't want to discuss the details about if that's discovery or composition. Just talk about it in the context of these examples.
Thomas: If we don't say the purpose of why are are doing this, people think that we don't know why are doing this.
Claudio: Finds composition example very useful in Telecom domain as well. composition can be used in recovery example
Thomas: We should be careful not to give the impression that this is all fully automatic. There will still be user intervention and this is not the whole picture - we are not dealing with NFP matching.
Carine: Keep the examples simple. Show what we are solving and talk about what we are not solving and addressing.
Rama: Add all of this in the intro in the example.
Jacek: Start with a simple discovery example. All blilling services in a given category.
... First concrete task. Restructuring, adding whatever we have talked about.
... Would like to go thought and suggest more best practices as he sees them here.
Carine: The spec and the examples doc don't have to be published at the same time. It can be published 2-3 weeks later.
Jacek: Editors are instructed to implement the restructuration, categorization scenario,
... The document will be tracked in every telecon. The editors will work on it and when it is in a resonable state, it will be published at that time.
Carlos: Wants to know if white board is an option for making calls
Jacek: Meeting adjourned