See also: IRC log
minutes from the 12/6 and 10/7 approved
pauld: ok, so we've added some
minOccurs patterns, been resurrecting our report (re-run
... yves has a hard-stop at 1:45, jon at 14:45
... so we have last call issues to answer, a databinding report to review, and a list of schemas in the wild to look at
... not being doing a great job of tracking LC issues thanks to issues with eXit
... let's look at the mail archive, the minutes from Nice and make sure we've not lost any
pauld: this is going to be painful, but let's make sure we have minuted RESOLUTIONS for all of them
we haven't done the polite thing and replied to the commenter
RESOLUTION: accepted and closed c-erh-1
RESOLUTION: accepted and closed lc-i18n-1
RESOLUTION: accepted and closed lc-i18n-2
RESOLUTION: accepted and closed c-i18n-3
RESOLUTION: accepted and closed lc-drkm-1
pauld: after testing, Microsoft are right, sequence with a cardinality not of 1 isn't well implemented
<scribe> ACTION: pdowney to move sequence patterns with minOccurs or maxOccurs !=1 to Advanced [recorded in http://www.w3.org/2007/08/03-databinding-minutes.html#action01]
<trackbot> Created ACTION-125 - Move sequence patterns with minOccurs or maxOccurs !=1 to Advanced [on Paul Downey - due 2007-08-10].
RESOLUTION: accepted and closed lc-Microsoft-3 as Advanced patterns
looking at our test report http://www.w3.org/2002/ws/databinding/examples/6/09/ElementReference/ is well supported and http://www.w3.org/2002/ws/databinding/examples/6/09/ElementReferenceUnqualified is already "Advanced"
gcowe: I agree with Microsoft
pauld: being cautious I'd want to remove it too
pauld: we discussed this in Nice and decided to at least add another pattern to ensure the reference was within the same schema document
jonc: doesn't everyone use this pattern?
pauld: um, not sure. I think for document/literal wrapped
some tools generate this?
... might be nice if our collection report listed patterns used in a roll-up report
gcowe: they asked to remove these patterns?
pauld: moved to advanced is what I think they meant
... I'm happy to move it to advanced based on what's used in the wild
jonc: we use it in our schemas/wsdls
pauld: internal ones?
jonc: I'll show you ..
pauld: so the BT "header" is an element referenced in another namespace and this works well with tools?
pauld: OK so we haven't seen evidence this doesn't work
RESOLUTION: reject lc-Microsoft-2 rejected based on testing
<gcowe> http://www.govtalk.gov.uk/gdsc/schemaHtml/AddressTypes-v1-4-xsd-UKPostalAddressStructure.htm demonstrates finite maxoccurs
pauld: will cover these in our collection: http://www.w3.org/2002/ws/databinding/edcopy/collection/
OK, so people use them, but from our report they don't work well with tools
RESOLUTION: accepted lc-Microsoft-5 finite maxOccurs patterns are Advanced
which examples exhibit this?
http://www.w3.org/2002/ws/databinding/examples/6/09/BareVector/ actually works fine
they say: "We suggest to recommend wrapped collection pattern as preferred" we can accept that .. I guess .. and "exclude bare array pattern"
which based on testing and how widely spread the pattern is we reject
<scribe> ACTION: pdowney to add advice that BareVector doesn't allow representation of null as opposed to empty arrays [recorded in http://www.w3.org/2007/08/03-databinding-minutes.html#action02]
<trackbot> Created ACTION-126 - Add advice that BareVector doesn\'t allow representation of null as opposed to empty arrays [on Paul Downey - due 2007-08-10].
RESOLUTION: accepted lc-Microsoft-7 in part
example doesn't exhibit their issue
pauld: so we haven't tested
... this pattern is very common with inheritence in OO
... we could add a pattern to Advanced to capture their issue?
... I don't think we need to given sequence with maxOccurs/minOccurs != 1 is now Advanced
so their issue is covered, but the pattern stays
RESOLUTION: rejected lc-Microsoft-8
AnyURIElement seems problematic with ZSI - they uriescape the URI
seems like the user of that tool would work around that issue, we use anyURI a *lot*
and we use ZSI ;-)
AttributeFixed failed in SOAP4R, it's an edge case - advanced?
pauld: no objections to making AttributeFixed "advanced"
AttributeOptional is Advanced
AttributeReference is definitely Advanced!
AtributeRequired fails in IBM and SOAP4R
AttributeTypeReference fails in Axis, Axis2 and others
gcowe: some of these are failing on boolean comparison
yves: will review the comparison
<gcowe> http://www.w3.org/2002/ws/databinding/edcopy/report/report_ibm_rad_java_7.0.html#AttributeRequired01 should be marked as boolean
so SOAP4R doesn't handle multiple attributes!
and we don't have specific tests for that
s/BooleanAttribute fails BooleanElement works, go figure!//
AttributeOptional is expressing the default!
let's keep that basic!
Base64BinaryAttribute is advanced
pauld: any examples based on a complete schema haven't been tested, including blockDefault, but these are mostly harmless
I raised a lc issue on Date and Time, but DateTime looks problematic
jonc: can't remove that
pauld: OK, so all dates, times and not datetime are advanced
gcowe: IBM tool seems to have a lot of issues in this area!
Decimal is advanced
ENTITY and ENTITIES are advanced, they barf and use DTDs
Axis 1.4 is behaving like a SOAP encoded toolkit, shockingly bad:
Float is advanced!
that's pretty fundamental
used by lots of schema generation tools
ID and IDREF don't work ID with ZSI
Integer is Advanced
and NonPositive - we don't have good test cases for
<Yves> need to add test for overflow detection
thanks Yves, see you next time!
Language fails in ZSI, not widespreadly used - Advanced
NMTOKEN/NMTOKENS is advanced
TypeSubstitutionUsingXsiType is Advanced
all the unsigned types are advanced
jonc: NillableOptional is definitely Advanced
pauld: agreed, with strong feeling!
we discussed this to death in ISSUE-7
jonc: nillable is something people want
pauld: i don't want it ;-)
gSOAP fails with nillable
we could argue that the echo test isn't fair to gSOAP here:
OK, let's keep Nillable
OK, let's regenerate the patterns, examples and reports ..
pauld: Thanks to George and Origo for hosting, once again!