- From: George Cowe <gcowe@origoservices.com>
- Date: Tue, 25 Mar 2008 11:51:57 -0000
- To: <public-xsd-databinding@w3.org>
I have updated the QualifiedLocalElements example so that it actually contains some qualified local elements!
http://www.w3.org/2002/ws/databinding/examples/6/09/QualifiedLocalElements/
For resolution of last call issue lc-xsd-9 (reference to Section 2.1.2 in http://lists.w3.org/Archives/Public/public-xsd-databinding-comments/2008Feb/0000.html )
George
-----Original Message-----
From: public-xsd-databinding-request@w3.org [mailto:public-xsd-databinding-request@w3.org] On Behalf Of paul.downey@bt.com
Sent: 19 March 2008 11:35
To: public-xsd-databinding@w3.org
Subject: Minutes: XML Schema Patterns for Databinding Telcon 18 March 2008
are now available:
http://www.w3.org/2002/ws/databinding/8/3/18-databinding-minutes.html
and copied below:
- DRAFT -
XML Schema Patterns for Databinding Working Group Teleconference
18 Mar 2008
See also: IRC log
Attendees
Present
Jon Calladine (BT)
George Cowe (Origo Services Limited)
Paul Downey (BT)
Yves Lafon (W3C)
Regrets
Chair
pauld
Scribe
pauld
Contents
* Topics
1. Patterns Detection
2. ISSUE-2: test suite
3. Charter Renewal?
4. Status of Basic Patterns
5. Last Call comments from Schema WG
6. lc-xsd-5
7. lc-xsd-6
8. lc-xsd-7
9. lc-xsd-8
10. lc-xsd-9
11. lc-xsd-10
12. lc-xsd-11 Editorial Concerns
13. Status of Publication
* Summary of Action Items
______________________________________________________________________________________________________________________
minutes from 2008-3-11 teleconference 2008-2-19 teleconference approved
Patterns Detection
pauld: built annotation
... see the examples and collection pages
gcowe: will look at optionally adding it to the service
http://www.w3.org/2002/ws/databinding/examples/6/09/DateAttribute/
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. Many thanks!
... 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
http://lists.w3.org/Archives/Public/public-xsd-databinding-comments/2008Feb/0000.html
lc-xsd-5
* 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?
*crickets*
RESOLUTION: lc-xsd-5 rejected
lc-xsd-6
* 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}"
http://www.w3.org/2002/ws/databinding/edcopy/basic/basic.html#assert-ProduceXML
pauld: anyone feel like they have better words for this assertion?
*crickets*
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
lc-xsd-7
* 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
lc-xsd-8
* 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
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"
RESOLUTION: accepted lc-xsd-5 as requiring clarification
lc-xsd-9
http://www.w3.org/TR/2007/WD-xmlschema-patterns-20071031/#group-SchemaElement
* 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
example something like:
<xs:element name="foo">
<xs:complexType>
<xs:sequence>
<xs:element ..
<xs:element ..
</xs:sequence>
</xs:complexType>
</xs:element
gcowe: will update example
RESOLUTION: accepted lc-xsd-9, will expand example
lc-xsd-10
* 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: OK, so whatabout our extensive use of boilerplate?
pauld: it's not a very human readable spec!
gcowe: it is computer generated
jonc: hard to avoid
>>>why<<<
pauld: we could have written another Schema primer, but our work has been driven by the test suite and our patterns
detector resulting in a concrete testable document. Without a strong proposal of contributed annotated text, I'm going to
push back.
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: in the past I have argued for 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.
RESOLUTION: 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]
E-mail disclaimer
The information in this e-mail is sent in confidence for the addressee only and may be legally privileged. Unauthorised recipients must preserve this confidentiality and should please advise the sender immediately of the error in transmission and then delete this e-mail. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on its content is prohibited and may be unlawful.
Origo Services Limited accepts no responsibility for any loss or damage resulting directly or indirectly from the use of this e-mail or the contents. It is your responsibility to scan for viruses. Origo Services Limited reserves the right to monitor e-mails sent to or from addresses under its control. When you reply to this e-mail, you are consenting to Origo Services Limited monitoring the content of the e-mails you send to or receive from Origo Services Limited. If this e-mail is non-business related Origo Services Limited is not liable for any opinions expressed by the sender. The contents of this e-mail are protected by copyright. All rights reserved.
Origo Services Limited is a company incorporated in Scotland (company number 115061) having its registered office at 4th floor, Saltire Court, 20 Castle Terrace, Edinburgh EH1 2EN.
Received on Tuesday, 25 March 2008 11:53:17 UTC