notes from 06/06/05

[John Fuller <jfuller@wernervas.com>]

eric:
   email on wrapping up context issues
   alistair: can BTP go on the list of transactions to discuss to go on 
agenda?
   eric: item on agenda to submit BTP?
   martin suggested we amend agenda and move on
1) Approve minutes from May 23rd,
   Greg sent around last meeting wrapup
   motion to approve from Mark
   kevin seconds the motion
2) review action items
   look at WSA to see SOAP 1.1
   Greg: SOAP 1.1 loses information
   need to get closure on fault model to wrapup WS-CTX
   on going discussion about status
3) issues discussion
   a) fault model
   Greg: mapping items for fault conditions to SOAP 1.2 and 1.1 bindings
   and additional header would avoid information loss in SOAP 1.1
   typically people accepted that they'd lose information in SOAP 1.1
   Martin: discussion in new orleans suggests we shouldn't add a new one
   Kevin: align with others sounds good even if we lose information
   Greg: consensus for motion to adopt current practice
   Kevin: adopt the bindings as outlined in Greg's email
   Mark seconds
   Tony: what's the problem with optional headers?
   Greg: built-in modeling to construct the messages
      hassle to create new headers using those tools
      but CAF likely implemented in a header mechanism anyway
   Eric: no objections so the motion is approved
   b) status type handling
   Mark and Alistair agreed it's reasonable to discuss abstract status
      semantic intent, and referencing specification to provide values
      Alistair: unfinished discussion from Redwood City: is it reasonable
        to have valued status at all?
      eric: separate issue from 262,
        which is a discussion of the status mechanism
      tony: currently optional overrideable values, doesn't necessarily 
conflict
      martin: agrees with tony
      alistair: agrees that if no mapping is necessary from the referencing
         specification, then it is not overly prescriptive
      tony: floating type provides useful values
      alistair: look to the text
      tony: align text to indicate the intent of overriding status values
      john: extending suggests mapping
      tony: extending the wrong word
      alistair: critical to not follow state transitions
         don't need to say we're ended because the end may be forked
      kevin: if uses ended status, then must follow specification
      doug: avoid using the word "restricting"
         semantics of values nailed down in context is good
         if referencing spec is slightly different, don't use those values
      alistair: retain description of states
         state transition diagram and first sentences excessively 
prescriptive
      eric: how to allow values to stay in the spec but allow for
         referencing specification to override
      alistair to write proposed amendment but the essence is that there
         are status values which many activities will use
         however a referencing specification is free to draw from and extend
         must not use active, completed, etc.
         alternately active to mean something else at a high level
      tony: wsctx:ACTIVE's definition is that in the CTX spec
         the reference spec's ACTIVE can be treated differently
      eric: sounds reasonable, alistair agrees,
         doug: formally we agree to an Action Item for Alistair to write
         kevin seconds, motion carried
      kevin: how to represent this within the schema?
         not tied into the type system yet
         substitution v. xsi types
         base status type is a qname with an enumeration type
         tony: comment in the schema and an example in the primer might help
         greg: agreed to put it in the primer
      eric:  status elements can be defined and redefined
      kevin: consider making type abstract, runtime substitution groups
      greg: problem is very few tool kits support substitution groups, jaxb
      enumerated types at each specification level and leave the element 
a qname
      alistair: advantage is no change necessary
4) context opacity
   kevin: previously the context element was within the header
   latest change overrides the type
   tony: propagation example supports the idea
      alternately describe an attribute that can go on any header
   eric: this is a common model for SOAP right now, intermediaries only deal
      with theirs
   kevin: application passthrough example
   martin: difficult to make propagation work properly
      context with a particular kind of flag
   alistair: endpoint can't be forced to do anything
      to continue in email
   can we make the mechanism to mandate propagation work?
   eric: first get through discussion about whether specs are correct
   kevin: submitting it as an item for discussion
   eric: better to identify behavior to support
   alistair: worth continuing to explore
   eric: we'll continue the current thread