Minutes: XML Schema Patterns for Databinding Telcon 18 March 2008

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Minutes: XML Schema Patterns for Databinding Telcon 18 March 2008

paul.downey

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]

Reply | Threaded
Open this post in threaded view
|

RE: Minutes: XML Schema Patterns for Databinding Telcon 18 March 2008

origogeo

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: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email]
Sent: 19 March 2008 11:35
To: [hidden email]
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.


Reply | Threaded
Open this post in threaded view
|

blockDefault action

jon.calladine

 For discussion on the call today please.

Action from last call:
http://www.w3.org/2008/03/18-databinding-minutes.html#action02

Noah points out that we are lumping any use of blockDefault into 1
pattern (./blockDefault) whereas there is a valid assignment
(blockDefault="") that is equivalent to the blockDefault attribute not
being present.

On the call last week we agreed that specifying any actual blocking
(ext/res/sub) was an advanced pattern but the natural conclusion is that
blockDefault="" is a basic pattern.

We either repurpose the existing basic pattern to catch this usage:

 - <pattern xml:id="BlockDefault" status="basic" origin="ISSUE-83"
groupid="SchemaElement">
<xpath>./@blockDefault=""</xpath>
</pattern>

and add a new pattern for the advanced usage

- <pattern xml:id="BlockDefaultExtResSub" status="advanced"
origin="ISSUE-83" groupid="SchemaElement">
<xpath>./@blockDefault and not(./@blockDefault)</xpath>
</pattern>

(plus changing examples accordingly)

or vice versa (ie make the existing pattern advanced and add a new basic
pattern)


I know we will find it hard to add new basic patterns at this stage so
suggest the former.

Reply | Threaded
Open this post in threaded view
|

Re: Minutes: XML Schema Patterns for Databinding Telcon 18 March 2008

Yi Wang-3
In reply to this post by origogeo

Hi George,

Thanks for updating the example. There is another issue with this
example - echoQualifiedLocalElements.wsdl is not valid. The attribute
'element' in message part 'echoQualifiedLocalElementsRequest' refers to
element 'ex:echoQualifiedLocalElements' which is not defined within the
WSDLfile. It was validated unsuccessfully using XMLSpy 2008. The WSDL
files in the following examples have similar problem:

     BlockDefault
     IncludeRelative
     QualifiedLocalAttributes
     UnqualifiedLocalElements
     UnqualifiedLocalAttributes
     ImportNamespace
     ImportSchemaNamespace
     ImportSchema
     ImportTypesNamespace
     FinalDefault
     SchemaVersion
     SOAPEncodedArray
     TargetNamespace
     NoTargetNamespace

     ElementTypeDefaultNamespace (namespace prefix missing from the
built-in type )

Regards,
Yi Wang
Objective Systems


George Cowe wrote:

> 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: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email]
> Sent: 19 March 2008 11:35
> To: [hidden email]
> 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.
>
>
>
>  

Reply | Threaded
Open this post in threaded view
|

RE: Minutes: XML Schema Patterns for Databinding Telcon 18 March 2008

origogeo

Hi

We believe we have corrected the issue you mention below concerning invalid WSDL for some of the examples and would like to ask you to rerun your tests.

The updated examples can be found at http://www.w3.org/2002/ws/databinding/testsuite/releases/examples-20080408.zip

Thanks for your patience!
George

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Yi Wang
Sent: 25 March 2008 16:16
To: George Cowe
Cc: [hidden email]
Subject: Re: Minutes: XML Schema Patterns for Databinding Telcon 18 March 2008


Hi George,

Thanks for updating the example. There is another issue with this
example - echoQualifiedLocalElements.wsdl is not valid. The attribute
'element' in message part 'echoQualifiedLocalElementsRequest' refers to
element 'ex:echoQualifiedLocalElements' which is not defined within the
WSDLfile. It was validated unsuccessfully using XMLSpy 2008. The WSDL
files in the following examples have similar problem:

     BlockDefault
     IncludeRelative
     QualifiedLocalAttributes
     UnqualifiedLocalElements
     UnqualifiedLocalAttributes
     ImportNamespace
     ImportSchemaNamespace
     ImportSchema
     ImportTypesNamespace
     FinalDefault
     SchemaVersion
     SOAPEncodedArray
     TargetNamespace
     NoTargetNamespace

     ElementTypeDefaultNamespace (namespace prefix missing from the
built-in type )

Regards,
Yi Wang
Objective Systems


George Cowe wrote:

> 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: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email]
> Sent: 19 March 2008 11:35
> To: [hidden email]
> 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.
>
>
>
>  


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.


Reply | Threaded
Open this post in threaded view
|

Re: Minutes: XML Schema Patterns for Databinding Telcon 18 March 2008

Ed Day-4

Hi George,

We re-ran all tests and our updated report can be found at the following URL:

http://www.obj-sys.com/w3cdatabinding/report_xbinder_c_1.4.html

The full updated test package is at the following location:

http://www.obj-sys.com/w3cdatabinding/xbinder14_w3cdb.zip

Regards,

Ed Day
Objective Systems, Inc.


On Tue, Apr 8, 2008 at 11:08 AM, George Cowe <[hidden email]> wrote:

> Hi
>
>  We believe we have corrected the issue you mention below concerning invalid WSDL for some of the examples and would like to ask you to rerun your tests.
>
>  The updated examples can be found at http://www.w3.org/2002/ws/databinding/testsuite/releases/examples-20080408.zip
>
>  Thanks for your patience!
>  George
>
>
>
>  -----Original Message-----
>  From: [hidden email] [mailto:[hidden email]] On Behalf Of Yi Wang
>  Sent: 25 March 2008 16:16
>  To: George Cowe
>  Cc: [hidden email]
>  Subject: Re: Minutes: XML Schema Patterns for Databinding Telcon 18 March 2008
>
>
>  Hi George,
>
>  Thanks for updating the example. There is another issue with this
>  example - echoQualifiedLocalElements.wsdl is not valid. The attribute
>  'element' in message part 'echoQualifiedLocalElementsRequest' refers to
>  element 'ex:echoQualifiedLocalElements' which is not defined within the
>  WSDLfile. It was validated unsuccessfully using XMLSpy 2008. The WSDL
>  files in the following examples have similar problem:
>
>      BlockDefault
>      IncludeRelative
>      QualifiedLocalAttributes
>      UnqualifiedLocalElements
>      UnqualifiedLocalAttributes
>      ImportNamespace
>      ImportSchemaNamespace
>      ImportSchema
>      ImportTypesNamespace
>      FinalDefault
>      SchemaVersion
>      SOAPEncodedArray
>      TargetNamespace
>      NoTargetNamespace
>
>      ElementTypeDefaultNamespace (namespace prefix missing from the
>  built-in type )
>
>  Regards,
>  Yi Wang
>  Objective Systems
>
>
>  George Cowe wrote:
>  > 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: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email]
>  > Sent: 19 March 2008 11:35
>  > To: [hidden email]
>  > 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.
>  >
>  >
>  >
>  >
>
>
>  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.
>
>



--
Ed Day
Objective Systems, Inc.
http://www.obj-sys.com

Reply | Threaded
Open this post in threaded view
|

RE: Minutes: XML Schema Patterns for Databinding Telcon 18 March 2008

origogeo

Thanks Ed, results look great.

Is there any way you can pass me the results from the test in the format required to populate the page
http://www.w3.org/2002/ws/databinding/edcopy/report/all.html
- this is just the output.xml file which we feed into the report builder.
See http://www.w3.org/2002/ws/databinding/edcopy/toolkits/xbinder_c_1.4/ for the previous one you provided.

Many thanks
George

-----Original Message-----
From: Ed Day [mailto:[hidden email]]
Sent: 12 May 2008 20:58
To: George Cowe
Cc: Yi Wang; [hidden email]
Subject: Re: Minutes: XML Schema Patterns for Databinding Telcon 18 March 2008

Hi George,

We re-ran all tests and our updated report can be found at the following URL:

http://www.obj-sys.com/w3cdatabinding/report_xbinder_c_1.4.html

The full updated test package is at the following location:

http://www.obj-sys.com/w3cdatabinding/xbinder14_w3cdb.zip

Regards,

Ed Day
Objective Systems, Inc.


On Tue, Apr 8, 2008 at 11:08 AM, George Cowe <[hidden email]> wrote:

> Hi
>
>  We believe we have corrected the issue you mention below concerning invalid WSDL for some of the examples and would like to ask you to rerun your tests.
>
>  The updated examples can be found at http://www.w3.org/2002/ws/databinding/testsuite/releases/examples-20080408.zip
>
>  Thanks for your patience!
>  George
>
>
>
>  -----Original Message-----
>  From: [hidden email] [mailto:[hidden email]] On Behalf Of Yi Wang
>  Sent: 25 March 2008 16:16
>  To: George Cowe
>  Cc: [hidden email]
>  Subject: Re: Minutes: XML Schema Patterns for Databinding Telcon 18 March 2008
>
>
>  Hi George,
>
>  Thanks for updating the example. There is another issue with this
>  example - echoQualifiedLocalElements.wsdl is not valid. The attribute
>  'element' in message part 'echoQualifiedLocalElementsRequest' refers to
>  element 'ex:echoQualifiedLocalElements' which is not defined within the
>  WSDLfile. It was validated unsuccessfully using XMLSpy 2008. The WSDL
>  files in the following examples have similar problem:
>
>      BlockDefault
>      IncludeRelative
>      QualifiedLocalAttributes
>      UnqualifiedLocalElements
>      UnqualifiedLocalAttributes
>      ImportNamespace
>      ImportSchemaNamespace
>      ImportSchema
>      ImportTypesNamespace
>      FinalDefault
>      SchemaVersion
>      SOAPEncodedArray
>      TargetNamespace
>      NoTargetNamespace
>
>      ElementTypeDefaultNamespace (namespace prefix missing from the
>  built-in type )
>
>  Regards,
>  Yi Wang
>  Objective Systems
>
>
>  George Cowe wrote:
>  > 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: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email]
>  > Sent: 19 March 2008 11:35
>  > To: [hidden email]
>  > 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.
>  >
>  >
>  >
>  >
>
>
>  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.
>
>



--
Ed Day
Objective Systems, Inc.
http://www.obj-sys.com

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.


Reply | Threaded
Open this post in threaded view
|

Re: Minutes: XML Schema Patterns for Databinding Telcon 18 March 2008

Yi Wang-3
Hi George,

Attached please find the output.zip file. Sorry I missed it in the
package. If you have any question on the result, please let us know.

Thanks!
Yi

George Cowe wrote:

> Thanks Ed, results look great.
>
> Is there any way you can pass me the results from the test in the format required to populate the page
> http://www.w3.org/2002/ws/databinding/edcopy/report/all.html
> - this is just the output.xml file which we feed into the report builder.
> See http://www.w3.org/2002/ws/databinding/edcopy/toolkits/xbinder_c_1.4/ for the previous one you provided.
>
> Many thanks
> George
>
> -----Original Message-----
> From: Ed Day [mailto:[hidden email]]
> Sent: 12 May 2008 20:58
> To: George Cowe
> Cc: Yi Wang; [hidden email]
> Subject: Re: Minutes: XML Schema Patterns for Databinding Telcon 18 March 2008
>
> Hi George,
>
> We re-ran all tests and our updated report can be found at the following URL:
>
> http://www.obj-sys.com/w3cdatabinding/report_xbinder_c_1.4.html
>
> The full updated test package is at the following location:
>
> http://www.obj-sys.com/w3cdatabinding/xbinder14_w3cdb.zip
>
> Regards,
>
> Ed Day
> Objective Systems, Inc.
>
>
> On Tue, Apr 8, 2008 at 11:08 AM, George Cowe <[hidden email]> wrote:
>  
>> Hi
>>
>>  We believe we have corrected the issue you mention below concerning invalid WSDL for some of the examples and would like to ask you to rerun your tests.
>>
>>  The updated examples can be found at http://www.w3.org/2002/ws/databinding/testsuite/releases/examples-20080408.zip
>>
>>  Thanks for your patience!
>>  George
>>
>>
>>
>>  -----Original Message-----
>>  From: [hidden email] [mailto:[hidden email]] On Behalf Of Yi Wang
>>  Sent: 25 March 2008 16:16
>>  To: George Cowe
>>  Cc: [hidden email]
>>  Subject: Re: Minutes: XML Schema Patterns for Databinding Telcon 18 March 2008
>>
>>
>>  Hi George,
>>
>>  Thanks for updating the example. There is another issue with this
>>  example - echoQualifiedLocalElements.wsdl is not valid. The attribute
>>  'element' in message part 'echoQualifiedLocalElementsRequest' refers to
>>  element 'ex:echoQualifiedLocalElements' which is not defined within the
>>  WSDLfile. It was validated unsuccessfully using XMLSpy 2008. The WSDL
>>  files in the following examples have similar problem:
>>
>>      BlockDefault
>>      IncludeRelative
>>      QualifiedLocalAttributes
>>      UnqualifiedLocalElements
>>      UnqualifiedLocalAttributes
>>      ImportNamespace
>>      ImportSchemaNamespace
>>      ImportSchema
>>      ImportTypesNamespace
>>      FinalDefault
>>      SchemaVersion
>>      SOAPEncodedArray
>>      TargetNamespace
>>      NoTargetNamespace
>>
>>      ElementTypeDefaultNamespace (namespace prefix missing from the
>>  built-in type )
>>
>>  Regards,
>>  Yi Wang
>>  Objective Systems
>>
>>
>>  George Cowe wrote:
>>  > 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: [hidden email] [mailto:[hidden email]] On Behalf Of [hidden email]
>>  > Sent: 19 March 2008 11:35
>>  > To: [hidden email]
>>  > 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.
>>  >
>>  >
>>  >
>>  >
>>
>>
>>  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.
>>
>>
>>    
>
>
>
>  

output.zip (48K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Minutes: XML Schema Patterns for Databinding Telcon 18 March 2008

origogeo

Thanks Yi

XBinder results have now been updated.
http://www.w3.org/2002/ws/databinding/edcopy/report/all.html

Regards
George


-----Original Message-----
From: Yi Wang [mailto:[hidden email]]
Sent: 13 May 2008 13:50
To: George Cowe
Cc: Ed Day; [hidden email]
Subject: Re: Minutes: XML Schema Patterns for Databinding Telcon 18 March 2008

Hi George,

Attached please find the output.zip file. Sorry I missed it in the package. If you have any question on the result, please let us know.

Thanks!
Yi

George Cowe wrote:

> Thanks Ed, results look great.
>
> Is there any way you can pass me the results from the test in the
> format required to populate the page
> http://www.w3.org/2002/ws/databinding/edcopy/report/all.html
> - this is just the output.xml file which we feed into the report builder.
> See http://www.w3.org/2002/ws/databinding/edcopy/toolkits/xbinder_c_1.4/ for the previous one you provided.
>
> Many thanks
> George
>
> -----Original Message-----
> From: Ed Day [mailto:[hidden email]]
> Sent: 12 May 2008 20:58
> To: George Cowe
> Cc: Yi Wang; [hidden email]
> Subject: Re: Minutes: XML Schema Patterns for Databinding Telcon 18
> March 2008
>
> Hi George,
>
> We re-ran all tests and our updated report can be found at the following URL:
>
> http://www.obj-sys.com/w3cdatabinding/report_xbinder_c_1.4.html
>
> The full updated test package is at the following location:
>
> http://www.obj-sys.com/w3cdatabinding/xbinder14_w3cdb.zip
>
> Regards,
>
> Ed Day
> Objective Systems, Inc.
>
>
> On Tue, Apr 8, 2008 at 11:08 AM, George Cowe <[hidden email]> wrote:
>  
>> Hi
>>
>>  We believe we have corrected the issue you mention below concerning invalid WSDL for some of the examples and would like to ask you to rerun your tests.
>>
>>  The updated examples can be found at
>> http://www.w3.org/2002/ws/databinding/testsuite/releases/examples-200
>> 80408.zip
>>
>>  Thanks for your patience!
>>  George
>>
>>
>>
>>  -----Original Message-----
>>  From: [hidden email]
>> [mailto:[hidden email]] On Behalf Of Yi Wang
>>  Sent: 25 March 2008 16:16
>>  To: George Cowe
>>  Cc: [hidden email]
>>  Subject: Re: Minutes: XML Schema Patterns for Databinding Telcon 18
>> March 2008
>>
>>
>>  Hi George,
>>
>>  Thanks for updating the example. There is another issue with this  
>> example - echoQualifiedLocalElements.wsdl is not valid. The attribute  
>> 'element' in message part 'echoQualifiedLocalElementsRequest' refers
>> to  element 'ex:echoQualifiedLocalElements' which is not defined
>> within the  WSDLfile. It was validated unsuccessfully using XMLSpy
>> 2008. The WSDL  files in the following examples have similar problem:
>>
>>      BlockDefault
>>      IncludeRelative
>>      QualifiedLocalAttributes
>>      UnqualifiedLocalElements
>>      UnqualifiedLocalAttributes
>>      ImportNamespace
>>      ImportSchemaNamespace
>>      ImportSchema
>>      ImportTypesNamespace
>>      FinalDefault
>>      SchemaVersion
>>      SOAPEncodedArray
>>      TargetNamespace
>>      NoTargetNamespace
>>
>>      ElementTypeDefaultNamespace (namespace prefix missing from the  
>> built-in type )
>>
>>  Regards,
>>  Yi Wang
>>  Objective Systems
>>
>>
>>  George Cowe wrote:
>>  > 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/QualifiedLocalEle
>> ments/
>>  >
>>  > 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/2
>> 008Feb/0000.html )  >  > George  >  >  >  >  > -----Original
>> Message-----  > From: [hidden email]
>> [mailto:[hidden email]] On Behalf Of
>> [hidden email]  > Sent: 19 March 2008 11:35  > To:
>> [hidden email]  > 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.
>>  >
>>  >
>>  >
>>  >
>>
>>
>>  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.
>>
>>
>>    
>
>
>
>  

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.