XML Schema Patterns for Databinding Working Group Teleconference

18 Mar 2008

See also: IRC log


George_Cowe, +0791888aaaa, pauld, Yves, jonc




<trackbot-ng> Date: 18 March 2008


pauld: built annotation
... see the examples and collection pages

gcowe: will look at optionally adding it to the service

minutes from 2008-3-11 teleconference 2008-2-19 teleconference approved


ISSUE-2: test suite

gcowe: the XBinder guys picked up an old copy of the testsuite and sent results

pauld: cool!

gcowe: we've added a load more tests, so I sent them a new copy

pauld: that's great. thx!
... collection is now checked in with annotation!
... what's next for the test suite?

gcowe: not a lot, we've run the tools we can, half the toolkits missing, Adrian had the ability to run them

pauld: but for basic, how do we stand?

<gcowe> http://www.w3.org/2002/ws/databinding/edcopy/report/basic.html

pauld: I can rerun SOAP4R and ZSI, can someone help with WCF

<Yves> I am doing gsoap c and c++

Charter Renewal?

pauld: dependent on publishing Last Call documents

yves: we should be able to ask for another six months

Status of Basic Patterns

pauld: thanks George for the work on differencing
... status section needs updating further

Last Call comments from Schema WG




* Schema documents vs. schemas: Following up on the point above, there are

schema documents that do not stand on their own in defining a schema

that's useful for validation. For example, if a schema document merely

defines a complext Type T as being derived by extension from type B with

attribute A, then you don't really know what the type is until you find

the base type B, and that may well be in a different schema document.

Maybe there is element content in effective type T. If there is an

element E declared of type T, then what does the requirement to "[expose]

all of the [XML 1.0] element node and attribute node content described by

the originating [XML Schema 1.0] document" mean? The problem is that it's

not really schema documents that directly call for or don't call for

content in documents to be validated. Schema documents contribute to the

construction of a schema (formally defined at [4]), which in turn contains

element declarations, etc. that can be used to require or allow content

in documents to be validated. >>It seems that some serious thought is

needed as to whether it's schema documents or schemas that would conform

to the databinding specification.<< In any case, referring to the

element or attribute content "described by a schema document" is not just

too informal; as suggested above, it's likely that you really want to

talk about the element or attribute content allowed by a schema.

Conversely, you could more clearly define a set of rules relating to

individual schema documents if that's what you really intend.


pauld: this is related to the infoset (v) document issue. It would be much harder to write test tools for this

yves: we're testing for bytes on the wire, not at the infoset level

pauld: the only way I could see this working is if they had an XML format for their infoset or even the PSVI
... anyone want to support this comment?


RESOLUTION: lc-xsd-5 rejected



* Section 1.4 says that conformance requires that an implementation: "MUST

be able to consume any well-formed [XML 1.0] document which satisfies

local-schema validity against the originating [XML Schema 1.0] document

exposing all of the [XML 1.0] element node and attribute node content in

the data model." Again, local-schema validity is not a relation defined

on the pair {instance, schema document}, it is (presuming you indicate

which type or element declaration to start with) defined on the pair

{instance, schema}"



pauld: anyone feel like they have better words for this assertion?


gcowe: let's ask them for better text!

<scribe> ACTION: pdowney to ask the Schema WG for advice [recorded in http://www.w3.org/2008/03/18-databinding-minutes.html#action01]

<trackbot-ng> Created ACTION-129 - Ask the Schema WG for advice [on Paul Downey - due 2008-03-25].

pauld: so we accept the comment, but don't have the skills to address it to schema WG's satisfaction


* Section 2: "The [XPath 2.0] expression is located from an [XML Schema

1.0] element node which may be the document element, or an element

contained inside an [XML 1.0] document such as [WSDL 2.0] description."

It's not quite clear what is meant in saying that an "[XPath 2.0]

expression is located from". Is this trying to establish the "Context

Node" for the XPath expression as being the node of the <xsd:schema>

element? If so, we recommend you say that more clearly, preferably with

hyperlinks to the pertinent parts of the XPath Recommendation. Also, the

phrase "may not" can be read as prohibiting the case where the element

note is the document node. I suspect you meant "need not". Finally, [XML

Schema 1.0] element node isn't a term that appears in the XSD

Recommendation; did you mean the "root element information item of the

schema document"?

pauld: accept "need not" change to text
... suggest a note to say "this is to establish the Context node for the XPath expression"
... seems reasonable to link to the XPath recommedation

RESOLUTION: accepted lc-xsd-7 with suggested text changes


* Sections 2.x: The phrase "An [XML 1.0] document exibits the XXXXX

pattern...." is used repeatedly in these sections and their descendents.

See comments about about need to refer to "schema documents", if that's

what's intended.

pauld: looks like the documents (v) infoset comment again

RESOLUTION: accepted lc-xsd-5 as requiring clarification

yves: is that the instance document?

pauld: we could be clearer that it's a WSDL 1.0, 2.0, Schema, whatever, but balooning the boilerplate isn't desirable
... we already have "2.1 Schema Element

The xs:schema element MAY be the document element, but MAY also appear within other descriptions such as a [WSDL 2.0] or [WSDL 1.1] document. †"

yves: text tied up better to the "An [XML 1.0] document exhibits the"



* Section 2.1.2: talks about qualified local elements, but the sample

schema contains no local elements.

pauld: we could change the example to include local elements

gcowe: what does that mean for the test suite? is this one excluded?

pauld: I suspect this is something we've excluded, so it could be safe

could risk introducing an advanced pattern

RESOLUTION: accepted lc-xsd-9, will expand example

example something like:

<xs:element name="echoDateAttribute">



<xs:element ref="ex:dateAttribute"/>




gcowe: will update example


* Section 2.1.6: BlockDefault. This pattern seems to imply that

substitutions and or derivations are blocked if the @blockDefault

attribute is provided, but in fact that attribute carries a value that can

selectively enable or disable blocking for any combination of extension,

restriction, and substitution. It seems unlikely that the rule of

interest is really that the attribute is present. Is that what's

intended, or did you wish to actually check for certain values of the

blockDefault. Note, in particular, that an explicit blockDefault="" has

the same semantic as leaving out the attribute entirely.

I regret that I did not have time to review the remainder of the patterns

in the draft, but I would assume that the above comments would be

representative of what would be found for other patterns.

jonc: mea culpa!
... pattern needs tightening up,

pauld: it's been moved to Advanced anyway

<scribe> ACTION: jcalladi to sort out BlockDefault patterns [recorded in http://www.w3.org/2008/03/18-databinding-minutes.html#action02]

<trackbot-ng> Created ACTION-130 - Sort out BlockDefault patterns [on Jonathan Calladine - due 2008-03-25].

RESOLUTION: accepted lc-xsd-10, BlockDefault has been moved to Advanced

lc-xsd-11 Editorial Concerns

The databinding draft is very long, and a lot of it is devoted to what is

ultimately boilerplate. Consider the targetNamespace pattern. It is

introduced with nearly 1/2 page of multicolor writeup, but really all it's

trying to say seems to be: This pattern requires that the schema

document have a targetNamespace attribute with an absolute URI as its

value. That could be said much more clearly and concisely. I think the

draft would be much more effective if the patterns were introduced in a

manner that was as concise and clear as possible. It's not helpful to

repeat over and over "An [XML 1.0] document exhibits....", and as noted

above, the example schema could be made shorter and clearer. Finally,

what would be most helpful for a pattern like this is to explain ">>why<<

an absolute URI"? The Schema recommendation points to the XML Namespaces

recommendation for the definition of a namespace name, and that in turn

requires a URI Reference [5], not an Absolute URI. So, it would be

useful in general if some of the boilerplate were eliminated and the

sections made much shorter and easier to read, but conversely it would be

useful to say a bit about what makes the pattern interesting. Explain

briefly if there's a reason why absolute namespace URIs are interesting,

or did you really just mean this pattern to be "a non-absent

targetNamespace is available"?

pauld: boilerplate?
... it's not a very human readable spec!

gcowe: it is computer generated

jonc: hard to avoid

pauld: without a concrete proposal, I'm going to push back. The work is in our testing and detector ..
... >>>why<<<

jonc: discussion was it's opening the flood gates, and this is for the primer

pauld: I know, I'm not keen on specs which justify themselves
... we're pretty clear why a pattern is Basic or Advanced
... we're not clear on how patterns come about
... sounds like something we could add as editorial text, volunteers?
... we've done a lot of work in terms of test tools and suites, and that' the best approach IMO

jonc: was in Noah's position, but it's seems best left to additional documents and discussion, on a wiki?

pauld: XML was famously wafted by Tim Bray as a small spec, then the first thing he did was publish an "annotated version". You're free to do the same :)
... I think its' fair comment to say why a pattern is interesting. Hmm. Will look at that generically in the introduction.

RESOULTION: accepted lc-xsd-11 in part, will add more introduction text

Status of Publication

pauld: all of the comments accepted are editorial, any objections to incorporating the text and then going ahead to Last Call as planned?

None heard

pickup again next tuesday

Summary of Action Items

[NEW] ACTION: jcalladi to sort out BlockDefault patterns [recorded in http://www.w3.org/2008/03/18-databinding-minutes.html#action02]
[NEW] ACTION: pdowney to ask the Schema WG for advice [recorded in http://www.w3.org/2008/03/18-databinding-minutes.html#action01]
[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.133 (CVS log)
$Date: 2008/03/18 16:12:22 $

Scribe.perl diagnostic output

[Delete this section before finalizing the minutes.]
This is scribe.perl Revision: 1.133  of Date: 2008/01/18 18:48:51  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: RRSAgent_Text_Format (score 1.00)

Succeeded: s/RESOLUTION: rejected as for lc-xsd-5/RESOLUTION: accepted lc-xsd-5 as requiring clarification/
Succeeded: s/Topic:/Topic: lc-xsd-11 Editorial Concerns/
Succeeded: s/;/:/
No ScribeNick specified.  Guessing ScribeNick: pauld
Inferring Scribes: pauld
Default Present: George_Cowe, +0791888aaaa, pauld, Yves, jonc
Present: George_Cowe +0791888aaaa pauld Yves jonc
Found Date: 18 Mar 2008
Guessing minutes URL: http://www.w3.org/2008/03/18-databinding-minutes.html
People with action items: jcalladi pdowney

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.

[End of scribe.perl diagnostic output]