See also: IRC log
minutes from the 24th approved
pauld: status of patterns and
... can people run the detector on their own schemas
george: does the detector follow
... it would be useful if it did
... i'll investigate
<scribe> ACTION: gcowe to investigate the patterns detector following import and include [recorded in http://www.w3.org/2006/11/07-databinding-minutes.html#action01]
<trackbot> Created ACTION-89 - Investigate the patterns detector following import and include [on George Cowe - due 2006-11-14].
pauld: following import/includes should be optional
jonc: we had interop issues so don't do a lot of import/including
pauld: be aware of loops
... building a collection of patterns detected in public schemas to go alongside our examples
yves: been looking at XMLUnit
pauld: will be at WSDL 2.0 event, would like to think about using it there
yves: can send work in progress
pauld: unlikely to effect code gen
RESOLUTION: close ISSUE-88 as a Basic Pattern
ISSUE-80, ISSUE-81, ISSUE-82, ISSUE-90
jonc: abstract='true' likely to
... we've rejected switching xsi:type as being Basic
we have: http://www.w3.org/2002/ws/databinding/examples/6/09/ComplexTypeSequenceExtension/
can't the base class be "abstract"?
jonc: most tools will ignore this, and probably allow an instance document to be created
gcowe: our experience wasn't great with abstract
jonc: can't see benefit in making
it basic when it's really for advanced patterns
... want to treat element and complexType separately
pauld: recalls seeing code-first
tools present interfaces as abstract='true'
... abstract='false' seems safe,
... i can see abstract elements being advanced, but complexType being basic
... it'll be at risk subject to test
RESOLUTION: accept abstract=false as a Basic Pattern, complexType abstract=true as a Basic Pattern and abstract element as Advanced
gcowe: are we going to take the same approach for all default attribute values?
created during the call
RESOLUTION: close ISSUE-92 as accepting default schema attributes explicitly set as Basic
jonc: introduces ISSUE-83, ISSUE-88, ISSUE-89
feels they should be Basic as they limit the use of xsi:type, even if they're ignored, they're unlikely to break anything
pauld: if we accept the attributes as Basic, do we have enough granularity to remove ones which don't work with tools?
jonc: these are mostly harmless
gcowe: if tools ignore them, is it a problem?
RESOLUTION: block, final and blockDefault, finalDefault are Basic Patterns, may be finer grained patterns in the document
pauld: in essence this is Russian Doll, used very widely, but we have encountered bad experiences with tools
jonc: we had problems with some in-support tools from big name vendors
pauld: do we put it in to rip out
under testing? leaving it out will be questioned
... prefer to make it Basic and test it
jonc: we need to make sure to add BEA 8.x and other mainstream tools to our testing
RESOLUTION: close ISSUE-84 as a Basic Pattern
pauld: this is really an issue with our test suite
RESOLUTION: close ISSUE-57 as Basic, examples needed
pauld: is widespreadly used, notably in the schema for schemas, no reason to say anything.
RESOLUTION: close ISSUE-73 with no action, examples would be useful
george: won't the test suite find this
pauld: if we add patterns and
examples for relative URIs and xml:base
... propose targetNamespace must be an absolute URI
RESOLUTION: close ISSUE-74 with pauld's proposal
this is a long standing issue
george: is one pattern is Basic and the others Advanced?
pauld: initially they're all proposed as being Basic, but under testing may be moved to advanced
yves: i'm ok so long as we call out we're not profiling, but trying to document interoperability
pauld: will write an editorial note raising the awareness of this issue being at risk
RESOLUTION: ISSUE-10 closed with paul's proposal
pauld: are we ready for Last Call?
RESOLUTION: close ISSUE-70 as a Basic Pattern
yves: we don't need to close all
issues to go to Last Call
... we can remove features marked as "at risk" all our patterns
pauld: our assertions aren't at
... my feeling is we need more text (editorial) and patterns and examples for all our closed issues (editorial)
... biggest danger is we have patterns missing for any very basic features
yves: we can make editorial changes after last call, non-normative changes can go onto CR/PR
pauld: how long do we need to give?
yves: 6 weeks is usual
pauld: that sits right during the
holiday season :-(
... ok lets do some editorial work and vote on it next week since we're heading for start of January anyway
yves: you can have a F2F during LC to answer issues
pauld: we may do that depending upon public reaction
pauld: in the meantime, please try the patterns detector on your schemas and report back on any missing patterns, especially ones which should be Basic