See also: IRC log
<trackbot> Date: 01 March 2011
<dug> scribe: Katy
Bob: Goal for CR vote 15th March
Resolution: Minutes approved
Bob: Any objection to accepting proposal in comment no 1 of proposal.
Doug: Describes proposal
Gil: Feel uneasy about this because
assigning semantic meaning to the empty string
... How about only making the Get the special case
Doug: What if someone wants to use the empty string as id value
Gil: That's associating special value
to ""
... we could have special string that means "unidentified" and
special case that
... within the W3C namespace
Doug: I don't think this is special semantics as it's indicated no identifier
Bob: Empty string might mean no value
Tom: What if there's an overloaded identifier that happens to be ""?
Gil: The point is a symbol to identify no useful Id - whether it's a "" or special URI
Doug: Initial problem was that the client doesn't know whether it needs an identifier or not.
Gil: So when types with identifier
defined those must be used, I am thinking of types with no
identifier
... specified
... Problem is we don't know all the dialects there may be some
types where we don't have an identifier. We should have a way to
put these things without an identifier if people choose not to -
but it's their problem
Doug: But that kills interop
Gil: disagree
Tom: In what scenario would someone not have an id for their metadata section?
Doug: If you know enough about the
metadata to 'put' it, you must put the appropriate identifier. If
it's optional then the clients always need to ask for
everything
... either mandate the use of identifier or there's no point in
it.
<trutt> If you require an id, but allow it to be "", it will all work
Katy: Id should not be optional or clients would have to assume it's not there
<Bob> that means that the set of values for the id attribute is empty
Bob: Empty identifier means set of values is empty/not present (in terms of XSLT test)
<trutt> "" is a value, it will test for presence
<Yves> optimization or not, absent and null value must be described
<Dave> Dave Snelling is lurking on tthe IRC only.
<trutt> "" is not a null value, it is a valid string "empty string" , not null
<trutt> if you test for presence of the value with "", it will be true in xpath. To test for "" you have to actually do a sting compare operation with "" as the compared value
Gil: We define enumerated set of dialects we know about. What we are discussing is, amongst those dialects, can you leave off the identifier? I agree with Doug that we can't allow folk to leave the Id off for the cases where the dialects/ids are defined.
<Bob> Java will return an empty string if there is no value defined
Doug: To ease confusion factor, I would like to require the identifier to be set (to "" or syntax string) else folk will think that absence = wildcard.
Tom: Schema point, technically speaking a default would work but it would cause more problems to have a default than to use "" - the latter makes it easier for xpath
Gil: I think we have agreed the
following 1) Put needs the type; 2) in some cases value of the type
is default which=""
... we need to say whether it is legal to put empty string for a
dialect that mex provides an identifier to
Doug: I agree, I think we have come full circle back to the proposal
<dug> <a foo='1'/> @foo != @foo2
<dug> oops, <a foo''/>
<dug> according to xml spy anyway
<gpilz> - make @Identifier a required attribute of mex:MetadataSection - if a metadata type does not have any useful data to use as the @Identifier value then it MUST use "" for the value - keep @Identifier optional on the mex:GetMetadata operation - mex:GetMetadata w/o @Identifier (not "") means match ALL @Identifiers
<gpilz> oops
<gpilz> - make @Identifier a required attribute of mex:MetadataSection
<gpilz> - you MAY use "" as the value of @Identifier except for those Dialects defined by WS-MEX
<gpilz> - keep @Identifier optional on the mex:GetMetadata operation
<gpilz> - mex:GetMetadata w/o @Identifier (not "") means match ALL @Identifiers
Doug: I will work on this text before the next meeting when we can review
Bob: Do we agree directionally so Dug can work on final text?
<scribe> ACTION: Doug to write up text based on comment one with some changes to 2nd bullet [recorded in http://www.w3.org/2011/03/01-ws-ra-minutes.html#action01]
<trackbot> Created ACTION-177 - Write up text based on comment one with some changes to 2nd bullet [on Doug Davis - due 2011-03-08].
Ram: Currently collecting feedback,
will have information in the next few days
... Wait until next call prior to confirming final answer
Bob: Defer to the next call
<dug> Puffin
Ram: No further testing required?
Bob: We will be producing new specs so we should crank through all the tests again
Ram: Previous mex issue need aditional testing?
Doug: Difficult to answer because the
issue is clarifying the semantics
... so to some may be no change
Ram: Recommend that we don't do unecessary testing as it has big resource issues
<Yves> we definitely have to test it, but that's what CR is all about
Bob: I would prefer to be conservative in our testing, even if just syntax change
Yves: Any changes to element needs to be re-tested if after CR
Bob: If we change the spec, we should
retest. Now we have gone through the process once, it should be
easier
... consider this when accepting the proposals
... we could defer 11776 so we can decide whether the test impact
too big
<dug> http://www.w3.org/2002/ws/ra/edcopies/wsevd.html#EVD_MIME
Bob: need to apply for the MIME type.
<scribe> ... done in link above
<trutt> given example xml doc
<trutt> <?xml version="1.0" encoding="UTF-8"?>
<trutt> <doc>
<trutt> <element atr1=""> "" </element>
<trutt> </doc>
<trutt> The following xpath returns the element:
<trutt> //element[@atr1=""]
<trutt> the following xpath does not return the element (no match) //element[@atr1=" "]
<trutt> Thus the "" is not comparable with " "
Bob: Items at risk are no longer at risk as we have adequate implementations for WS-Eventing and WS-Enum
Bob: Clash with cloud management meeting on 8th so we will have next meeting on the 15th and meeting on 22nd
<Ram> ï¶ WS-Enumeration test coverage analysis to be completed by Microsoft.
<Ram> Test coverage analysis actions:
<Ram> WS-Enumeration test coverage analysis to be completed by Microsoft.
<Ram> WS-Eventing test coverage analysis to be analysis by Avaya.
<Ram> WS-Transfer/WS-Fragment test coverage analysis to be analysis by IBM.
<Ram> WS-MEX test coverage analysis to be analysis by Oracle.
Gil: Why aren't faults defined in the WSDL in the W3C specs?
Tom: If SOAP faults they can happen anywhere so don't need to be defined in the WSDL
<dug> answer: we're lazy
<dug> answer: 'cause
<dug> answer: go away, use REST
<Bob> just log them
<dug> would we need a union to express multiple faults could be returned?
Gil: will look into this and decide whether issue or not next meeting