Nabble - w3.org - public-ws-desc-comments

Missing wsdli:wsdlLocation in example

2009-06-17T07:20:18Z

Example 5-9 (http://www.w3.org/TR/wsdl20-primer/#reservationDetails.xsd) in the specification does not show the use of the wsdli:wsdlLocation attribute as stated in the text.

Here is the text below the example:

This XML schema contains the usual definitions for the elements that appear in the messages of the Web service. For example, the reservationDetails element is used in the messages of the retrieve and update operations. In addition, the schema defines the simple type reservationDetailsSOAPEndpointType which is based on xs:anyURI and has the annotation wsdlx:binding = "wdetails:reservationDetailsSOAPBinding" which means that the URI is the address of a Reservation Details Web service endpoint that implements the wdetails:reservationDetailsSOAPBinding binding. Note that the wsdli:wsdlLocation attribute is used to define the location of the WSDL 2.0 document that defines the wdetails:reservationDetailsSOAPBinding binding. This annotated simple type is used to define the reservationDetailsSOAPEndpoint element which will be used in the Reservation List service.

And here is the referred XML:

<?xml version="1.0" encoding="UTF-8"?>
<schema . . .
        xmlns:wsdli="http://www.w3.org/ns/wsdl-instance"
        . . . >


        . . .

        <simpleType name="reservationDetailsSOAPEndpointType" wsdlx:binding="wdetails:reservationDetailsSOAPBinding">
                <restriction base="anyURI"/>

        </simpleType>

        . . .
</schema>

Best regards,
--
Moisés Braga Ribeiro
moisesbr@...

Re: TR/2007/REC-wsdl20-20070626/wsdl20-z.html#zed-InterfaceParent

2009-02-12T08:08:46Z

Mark,

Sorry for the delayed responce (on vacation). Thx for your careful review of the spec. Could you please open a bug so we can track this properly? [1]

[1] http://www.w3.org/Bugs/Public/

Arthur Ryman, IBM DE
Chief Architect, Rational Project and Portfolio Managent
Office: 905-413-3077, Cell: 416-939-5063
Assistant: Florence Turgeon, 905-413-4182

"Josephs, Mark Brian" <mark.josephs@...>

01/17/2009 08:54 PM

To	Arthur Ryman/Toronto/IBM@IBMCA
cc	<public-ws-desc-comments@...>
Subject	TR/2007/REC-wsdl20-20070626/wsdl20-z.html#zed-InterfaceParent

Dear Dr. Ryman,
Please consider correcting the predicate part of the InterfaceParent schema. As things stand, interfaceFaultComps is unconstrained if interfaceOpComps is an empty set in a given ComponentModel2, i.e., the predicate part could be simplified to true. Likewise, interfaceOpComps is unconstrained if interfaceFaultComps is an empty set.
Correction is straightforward: each constraint should be expressed in a separate universal quantification.
Yours sincerely,
Mark
Prof. Mark B. Josephs
Faculty of BCIM
London South Bank University
http://www.bcim.lsbu.ac.uk/ccsv/josephmb/

--
Email has been scanned for spam and viruses by Altman Technologies' email management service

--
Copyright in this email and in any attachments belongs to London South Bank University. This email, and its attachments if any, may be confidential or legally privileged and is intended to be seen only by the person to whom it is addressed. If you are not the intended recipient, please note the following: (1) You should take immediate action to notify the sender and delete the original email and all copies from your computer systems; (2) You should not read copy or use the contents of the email nor disclose it or its existence to anyone else.

The views expressed herein are those of the author(s) and should not be taken as those of London South Bank University, unless this is specifically stated.

London South Bank University is a company limited by guarantee registered in England and Wales. The following details apply to London South Bank University: Company number - 00986761; Registered office and trading address - 103 Borough Road London SE1 0AA; VAT number - 778 1116 17; Email address - lsbuinfo@...

wrong link in WSDL primer

2008-09-05T02:19:52Z

Dear W3Cers,

I noticed a wrong link in the references in the WSDL primer. The link
"Web Services Architecture" refers wrongly to the "Architecture of the WWW
volume 1".

Best regards,

Jan Van den Bussche
Hasselt University, Belgium

Call for support in building SAWSDL Service Test Collection

2008-06-26T11:05:54Z

Dear colleagues,

I would like to kindly ask for your support in collecting SAWSDL
services for an initial test collection.
We aim to use this collection for measuring retrieval performance
and scalability of SAWSDL matchmakers (for example in the upcoming S3
Semantic Service Selection contest).

So far, we have an initial retrieval test collection SAWSDL-TC1 beta
deduced from the collection OWLS-TC2 (by help of conversion tools and
manual work) and collected SAWSDL services from different sources
in the Web we came across. This beta version contains
actually more than 800 services and 28 queries (formulated as desired
SAWSDL services).

But for sure there is a lot more somewhere, especially in hidden project
repositories. So, this is a desparate call for your help in finding
and collecting SAWSDL services of all degrees of complexity.
Even if the incentive to do so is low in terms of money and time,
means actually zero, i know :-( - we nevertheless could do at least
such initial steps together in building such a test collection over
time.

We would therefore appreciate any help in this matter: You can send us
your
- SAWSDL services, and/or
- one or more queries formulated as a desired SAWSDL service
together with binary relevance set (= set of SAWSDL services
you think are relevant)
in a zip-file.

Depending on the feedback, we will then put the first version of
the collection SAWSDL-TC1 online such that we then can jointly add and
modify it continuously online and/or at the next S3 contest at the SMR2
workshop of the International Semantic Web Conference in Karlsruhe by
end of October.

Thanks for your very idealistic support and effort in advance!

Best regards,
Matthias

PS: We beg for your understanding that we do *not* publish
our SAWSDL-TC1 beta right now.

-------------------------------------------------------------
Dr. Matthias Klusch
German Research Center for Artificial Intelligence (DFKI)
Stuhlsatzenhausweg 3, 66123 Saarbruecken, Germany
Phone: +49-681-302-5297, Fax: +49-681-302-2235
http://www.dfki.de/~klusch/
-------------------------------------------------------------
Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH
Firmensitz: Trippstadter Strasse 122, D-67663 Kaiserslautern
Geschaeftsfuehrung:
Prof. Dr. Dr. h.c. mult. Wolfgang Wahlster (Vorsitzender)
Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats:
Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
-------------------------------------------------------------

RE: error in the WSDL primer

2007-10-11T10:40:24Z

Gerd,

The address property of the endpoint is actually optional. There is no requirement in the spec that it is unique within a service. Only the name property of the endpoint must be unique within a service.

Yes, I expect Web service runtimes like Axis2 to support mixed SOAP 1.1/1.2 environments as well as mixed WSDL 1.1/2.0. Woden is WSDL 2.0 only now but we'd like it to provide WSDL 1.1 support eventually.

Arthur Ryman, PhD, AoT, DE
Process and Portfolio Management, Rational Division

phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-3831 (T/L: 318-8867)
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@...

"Gerd Wagner" <wagnerg@...>
Sent by: public-ws-desc-comments-request@...

10/11/2007 09:19 AM

To	Arthur Ryman/Toronto/IBM@IBMCA
cc	<public-ws-desc-comments@...>, <public-ws-desc-comments-request@...>
Subject	RE: error in the WSDL primer

I don't think that's an error. You could have an endpoint that supported both SOAP 1.1 and SOAP 1.2. The service could check the envelope to determine which SOAP version was being used, and respond in that format.

Yes, I understand, this would be possible. But is this the intended meaning? That is, do endpoint addresses not have to be unique acording to the sepc?

Even if this would be the official WSDL definition, do you expect that WSDL tools, such as Woden/Axis2 will allow this?

-Gerd
I'd like to report an error in the WSDL example "Example 2-13. SOAP 1.2 and SOAP 1.1 Bindings" of the WSDL primer http://www.w3.org/TR/2007/REC-wsdl20-primer-20070626 Both endpoints have the same address, which is wrong (according to my understanding of endpoints). Regards, Gerd Wagner -------------------------------------------- Professor Gerd Wagner http://oxygen.informatik.tu-cottbus.de/IT Email: G.Wagner@... Tel: (+49 355) 69 2397 Institute of Informatics Brandenburg University of Technology at Cottbus, Germany

RE: error in the WSDL primer

2007-10-11T07:19:03Z

I don't think that's an error. You could have an endpoint that supported both SOAP 1.1 and SOAP 1.2. The service could check the envelope to determine which SOAP version was being used, and respond in that format.

Yes, I understand, this would be possible. But is this the intended meaning? That is, do endpoint addresses not have to be unique acording to the sepc?

Even if this would be the official WSDL definition, do you expect that WSDL tools, such as Woden/Axis2 will allow this?

-Gerd

I'd like to report an error in the WSDL example "Example 2-13. SOAP 1.2 and SOAP 1.1 Bindings" of the WSDL primer http://www.w3.org/TR/2007/REC-wsdl20-primer-20070626 Both endpoints have the same address, which is wrong (according to my understanding of endpoints). Regards, Gerd Wagner -------------------------------------------- Professor Gerd Wagner http://oxygen.informatik.tu-cottbus.de/IT Email: G.Wagner@... Tel: (+49 355) 69 2397 Institute of Informatics Brandenburg University of Technology at Cottbus, Germany

Re: error in the WSDL primer

2007-10-11T06:54:29Z

Gerd,

I don't think that's an error. You could have an endpoint that supported both SOAP 1.1 and SOAP 1.2. The service could check the envelope to determine which SOAP version was being used, and respond in that format.

Arthur Ryman, PhD, AoT, DE
Process and Portfolio Management, Rational Division

phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-3831 (T/L: 318-8867)
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@...

"Gerd Wagner" <wagnerg@...>
Sent by: public-ws-desc-comments-request@...

10/11/2007 07:42 AM

To	<public-ws-desc-comments@...>
cc
Subject	error in the WSDL primer

I'd like to report an error in the WSDL example "Example 2-13. SOAP 1.2 and SOAP 1.1 Bindings" of the WSDL primer http://www.w3.org/TR/2007/REC-wsdl20-primer-20070626 Both endpoints have the same address, which is wrong (according to my understanding of endpoints). Regards, Gerd Wagner -------------------------------------------- Professor Gerd Wagner http://oxygen.informatik.tu-cottbus.de/IT Email: G.Wagner@... Tel: (+49 355) 69 2397 Institute of Informatics Brandenburg University of Technology at Cottbus, Germany

error in the WSDL primer

2007-10-11T05:42:05Z

I'd like to report an error in the WSDL example
"Example 2-13. SOAP 1.2 and SOAP 1.1 Bindings"
of the WSDL primer
http://www.w3.org/TR/2007/REC-wsdl20-primer-20070626

Both endpoints have the same address, which is
wrong (according to my understanding of endpoints).

Regards,
Gerd Wagner

--------------------------------------------
Professor Gerd Wagner
http://oxygen.informatik.tu-cottbus.de/IT
Email: G.Wagner@...
Tel: (+49 355) 69 2397
Institute of Informatics
Brandenburg University of Technology
at Cottbus, Germany

seems editorial mistake

2007-10-10T12:11:16Z

2.3.2 XML Representation of Interface Fault Component say as follows:

<description>    <interface>      <fault            name="xs:NCName"             element="union of xs:QName, xs:token"? >       
 <documentation />*      </fault>    </interface>  </description>

I think </fault>* seems correct.

rock

2007-09-24T15:33:29Z

Sex Pistols add two reunion shows

Punk legends The Sex Pistols have added two additional shows to their
London reunion in November.

They will now play the Brixton Academy on 9 and 10 November in addition
to their 8 November concert.

The gigs were added after tickets for the one-off event, which cost
£37.50, were snapped up within 10 minutes.

The event was announced to celebrate the 30th anniversary of the band's
seminal Never Mind The Bollocks album. All three
gigs have now sold out.

Defining records

Original members John Lydon, Steve Jones, Paul Cook and Glen Matlock
will perform at the concerts.

The group, who split in 1978, first reformed for a world tour in 1996
and last performed together in 2003.

Never Mind The Bollocks... Here's The Sex Pistols, which included God
Save the Queen and Anarchy in the UK, caused
uproar when it was released in October 1977.

But it was one of the defining records of the punk movement and is now
recognised as one of the most influential albums in
rock history.

http://www.wholeearthphonesex.com
http://www.phone-sex-psychologist.com
http://www.phone-sex-hypnosis.com
http://www.phone-sex-dictionary.com
http://www.phone-sex-handjobs.com
http://www.your-account.info
http://www.freephonesex.org
http://www.1800phonesex.net
http://www.1on1phonesex.com
http://www.phonesexphone.com
http://www.hotphone.com
http://www.xxx-rated.com

Introduction

2007-09-08T07:30:31Z

Hi all,

I just subscribed to this list and wanted to introduce myself before posting. I'm Rob and coding and design is my hobby. So do nothing fancy but think I can learn a lot from all posts coming by in this W3C mailinglist.

I have a portal called Indelv.com (http://www.indelv.com/) and post some news on standards just to keep track of what is happening in the field. I know the site is not fully standardized, but I am working on it when I have free time.

So if you have some cool news or found a nice article, send me a note, I will repost some of it on Indelv, so I will not loose track of it. Hope I see nice tips passing by on this mailing list and in the future I might be a bit better and can even assist with answers.

Kind regards and have a good weekend

Rob

Marketing Online SEO and W3

2007-08-01T06:11:40Z

Is there any certification for Marketing Online SEO and W3

Marketing Online SEO

http://www.lososeans.info

Hotmail to go? Get your Hotmail, news, sports and much more! Check out the New MSN Mobile

Re: SOAP Modules (WSDL Version 2.0 Part 2: Adjuncts)

2007-06-22T15:44:54Z

On Wed, 2007-06-20 at 13:23 -0400, twolff@... wrote:
> Now that support for features and properties has been removed, support for SOAP
> modules should also be removed, or at least flagged as an at-risk feature.

1. SOAP modules are part of the SOAP 1.2 recommendation, so if we want
to provide a full support for SOAP 1.2, we should have the SOAP modules
as well.

2. We tested this part a long time and reached the CR exit criteria for
that, so we know it isn't at-risk.

3. the CR phase is long gone and this request is wait too late in the
process for us to even consider.

Philippe

RE: SOAP Modules (WSDL Version 2.0 Part 2: Adjuncts)

2007-06-22T08:36:47Z

The Working Group did consider this fully when features and properties were removed, but felt that there still was utility in supporting SOAP 1.2 functionality including modules even without a larger f&p framework.

As the final vote for moving WSDL 2.0 to Recommendation status closed yesterday, and the Working Group charter expires at the end of the mongth, I'm afraid we won't be able to revisit this decision in light of your comment.

Jonathan Marsh - http://www.wso2.com - http://auburnmarshes.spaces.live.com

> -----Original Message-----
> From: public-ws-desc-comments-request@... [mailto:public-ws-desc-
> comments-request@...] On Behalf Of twolff@...
> Sent: Wednesday, June 20, 2007 10:24 AM
> To: public-ws-desc-comments@...
> Subject: SOAP Modules (WSDL Version 2.0 Part 2: Adjuncts)
>
>
> Now that support for features and properties has been removed, support
> for SOAP
> modules should also be removed, or at least flagged as an at-risk
> feature.

SOAP Modules (WSDL Version 2.0 Part 2: Adjuncts)

2007-06-20T11:23:58Z

Now that support for features and properties has been removed, support for SOAP
modules should also be removed, or at least flagged as an at-risk feature.

Response to your WSDL RDF Mapping comments

2007-05-20T10:05:27Z

Dear Karl,

last August, we have received your QA review of the WSDL RDF mapping
document [1]. Your comments were logged as issues in [2], in particular
issues 293 to 298. This email contains my responses (as the main editor
of the document); I tried to implement the intent of your suggestions as
much as I could.

293: section 2.1.1 is now clarified to show that the "assumption" is not
normative and does not affect interop in scope of the document.
Discussion of handling of inconsistency issues when merging SemWeb data
is out of scope here.

294: the introduction (Sec 1) now mentions several various options wrt.
implementing the RDF mapping

295, 296: the document now contains a conformance section.

297: the mapping of unknown extensions in the WSDL RDF mapping spec was
removed because either SemWeb tools don't have a good support for
working with XML (which would be required to get useful information from
the XML Literal which used to represent unknown extensions) or, if they
support XML, there is no reason they shouldn't use the WSDL directly.
Known extensions are mapped to RDF according to whatever the extension
says.

298: editorial, most comments implemented, some still waiting as "todo"s
in the document.

Thanks a lot for the comments, they were very useful,
Jacek Kopecky

[1] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-rdf.html?content-type=text/html;%20charset=utf-8
[2] http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/ws/desc/issues/wsd-issues.html

WSDL 2.0 references

2007-05-17T08:16:06Z

Hello Mohamed,

I'm trying to make I get the references right this time in the WSDL 2.0
documents. Hopefully, I now fix everything using [2] and [3].

The editors' copies of the document should be fine now.

Regards,

Philippe

[1]
http://lists.w3.org/Archives/Public/public-ws-desc-comments/2007May/0010.html
[2] http://www.w3.org/2004/07/references-checker-ui
[3] http://www.w3.org/2007/05/ietf-references-checker

Re: Comment on Web Services Description Language (WSDL) Version 2.0 Part 0: Primer

2007-05-10T11:55:04Z

On 5/10/07, Innovimax SARL <innovimax@...> wrote:

> Great !
>
> The reference have not been fully corrected
>
> And I see new ones in all the specs
>
> [[
> [IETF RFC 3023]
> "XML Media Types", M. Murata, S. St. Laurent, D. Kohn, Authors.
> Internet Engineering Task Force, January 2001. Available at
> http://www.ietf.org/rfc/rfc3023.txt.
> ]]
>
> [[
> [XLink 1.0]
> XLink 1.0 Steve DeRose, Eve Maler, David Orchard, Editors. World
> Wide Web Consortium, 27 June 2001. This version of the XLink
> Recommendation is http://www.w3.org/TR/2001/REC-xlink-20010627/ The
> latest version of XLink is available at http://www.w3.org/TR/xlink/.
> ]]
>
> [[
> [XForms 1.0]
> XForms 1.0 (Second Edition), M. Dubinko, et al., Editors. World
> Wide Web Consortium, 14 March 2006. This version of the XForms 1.0
> Recommendation is http://www.w3.org/TR/2006/REC-xforms-20060314/. The
> latest version of XForms 1.0 is available at
> http://www.w3.org/TR/xforms/.
> ]]
>
> [[
> [SOAP12 Part 1]
> SOAP Version 1.2 Part 1: Messaging Framework (Second Edition), M.
> Gudgin, M. Hadley, N. Mendelsohn, J-J. Moreau, H. Frystyk Nielsen,
> Editors. World Wide Web Consortium, 27 April 2007. This version of the
> "SOAP Version 1.2 Part 1: Messaging Framework" Recommendation is
> http://www.w3.org/TR/2007/REC-soap12-part1-20070427/. The latest
> version of "SOAP Version 1.2 Part 1: Messaging Framework" is available
> at http://www.w3.org/TR/soap12-part1/.
> ]]
>
> In http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-soap11-binding.html?content-type=text/html;%20charset=utf-8#References
>
> Reference to XSD Structures and XSD Datatypes are not to last version
> (second edition)
>
>
> But now some information in the text are to be revised
>
> In http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-primer.html
>
> [[
> 1.1 Prerequisites
>
> This primer assumes that the reader has the following prerequisite knowledge:
> * familiarity with XML (Extensible Markup Language (XML) 1.0
> (Second Edition) [XML 1.0], XML Information Set [XML Information Set])
> and XML Namespaces (Namespaces in XML [XML Namespaces]);
> * some familiarity with XML Schema (XML Schema Part 1: Structures
> [XML Schema: Structures] XML Schema Part 2: Datatypes [XML Schema:
> Datatypes]);
> * familiarity with basic Web services concepts such as Web
> service, client, and the purpose and function of a Web service
> description. (For an explanation of basic Web services concepts, see
> Web Services Architecture [WS Architecture] Section 1.4 and Web
> Services Glossary [WS Glossary] glossary. However, note the Web
> Services Architecture document uses the slightly more precise terms
> "requester agent" and "provider agent" instead of the terms "client"
> and "Web service" used in this primer.)
>
> No previous experience with WSDL is assumed.
> ]]
>
> I propose to remove " (Second Edition)"
>
> Mohamed ZERGAOUI
> Innovimax AC Rep
>
>
> On 5/10/07, Jonathan Marsh <jonathan@...> wrote:
> > Thank you for this issue. We tracked it as Issue 4427 [1] in our short Last Call period. The Working Group endeavored to correct all the bib references in all the specs [2,3,4,5,6].
> >
> > The spec should be in Proposed Recommendation shortly, if you disagree with the resolution of this issue please inform us as soon as possible.
> >
> > [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4457
> > [2] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-primer.html
> > [3] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html?content-type=text/html;%20charset=utf-8
> > [4] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-adjuncts.html?content-type=text/html;%20charset=utf-8
> > [5] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-soap11-binding.html?content-type=text/html;%20charset=utf-8
> > [6] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-rdf.html?content-type=text/html;%20charset=utf-8
> >
> > Jonathan Marsh - http://www.wso2.com - http://auburnmarshes.spaces.live.com
> >
> > > -----Original Message-----
> > > From: public-ws-desc-comments-request@... [mailto:public-ws-desc-
> > > comments-request@...] On Behalf Of Innovimax SARL
> > > Sent: Sunday, April 08, 2007 12:49 PM
> > > To: public-ws-desc-comments@...
> > > Subject: Comment on Web Services Description Language (WSDL) Version
> > > 2.0 Part 0: Primer
> > >
> > >
> > > Please find below listed a lot of errors in the References
> > >
> > > Please note also that errors could also be found in other part of the
> > > spec
> > > * WSDL 2.0 Core
> > > * WSDL 2.0 Adjuncts
> > > * WSDL 2.0 SOAP 1.1 Binding
> > > * WSDL 2.0 RDF Mapping
> > >
> > > Best regards,
> > >
> > > Mohamed ZERGAOUI
> > > Innovimax AC Rep
> > >
> > >
> > >
> > >
> > > In Web Services Description Language (WSDL) Version 2.0 Part 0: Primer
> > > W3C Working Draft 26 March 2007
> > > http://www.w3.org/TR/2007/WD-wsdl20-primer-20070326
> > >
> > > Normative Reference :
> > >
> > > "Key words for use in RFCs to Indicate Requirement Levels, S. Bradner,
> > > Author. Internet Engineering Task Force, March 1997. Available at
> > > http://www.ietf.org/rfc/rfc2119.txt."
> > > instead of
> > > "Key words for use in RFCs to Indicate Requirement Levels, S. Bradner,
> > > Author. Internet Engineering Task Force, June 1999. Available at
> > > http://www.ietf.org/rfc/rfc2119.txt."
> > >
> > > [[
> > > [IETF RFC 3023]
> > > XML Media Types", M. Murata, S. St. Laurent, D. Kohn, Authors.
> > > Internet Engineering Task Force, January 2001. Available at
> > > http://www.ietf.org/rfc/rfc3023.txt.
> > > ]]
> > > instead of
> > > [[
> > > [RFC 3023]
> > > IETF "RFC 3023: XML Media Types", M. Murata, S. St. Laurent, D.
> > > Kohn, July 1998.(Seehttp://www.ietf.org/rfc/rfc3023.txt.)
> > > ]]
> > >
> > > XML (Fourth Edition) instead of (third)
> > > Namespaces in XML 1.0 (Second Edition) instead of Namespace in XML
> > > XML Schema Part 1: Structures Second Edition instead of XML Schema
> > > Part 1: Structure
> > > XML Schema Part 2: Datatypes Second Edition instead of XML Schema Part
> > > 2: Datatypes
> > >
> > > In Informative Reference
> > >
> > > "XPointer Framework, Paul Grosso, Eve Maler, Jonathan Marsh, Norman
> > > Walsh, Editors. World Wide Web Consortium, 25 March 2003"
> > > instead of
> > > "XPointer Framework,Paul Grosso, Eve Maler, Jonathan Marsh, Norman
> > > Walsh, Editors. World Wide Web Consortium, 22 November 2002."
> > >
> > > "XML Schema Versioning Use Cases, Hoylen Sue. W3C XML Schema Working
> > > Group Draft, 31 January 2006. Available at
> > > http://www.w3.org/XML/2005/xsd-versioning-use-cases/"
> > > instead of
> > > "XML Schema Versioning Use Cases , Hoylen Sue. W3C XML Schema Working
> > > Group Draft, 15 April 2005. Available at
> > > http://www.w3.org/XML/2005/xsd-versioning-use-cases/"
> > >
> > > --
> > > Innovimax SARL
> > > Consulting, Training & XML Development
> > > 9, impasse des Orteaux
> > > 75020 Paris
> > > Tel : +33 8 72 475787
> > > Fax : +33 1 4356 1746
> > > http://www.innovimax.fr
> > > RCS Paris 488.018.631
> > > SARL au capital de 10.000 €
> >
> >
>
>
> --
> Innovimax SARL
> Consulting, Training & XML Development
> 9, impasse des Orteaux
> 75020 Paris
> Tel : +33 8 72 475787
> Fax : +33 1 4356 1746
> http://www.innovimax.fr
> RCS Paris 488.018.631
> SARL au capital de 10.000 €
>

--
Innovimax SARL
Consulting, Training & XML Development
9, impasse des Orteaux
75020 Paris
Tel : +33 8 72 475787
Fax : +33 1 4356 1746
http://www.innovimax.fr
RCS Paris 488.018.631
SARL au capital de 10.000 €

RE: Is an assertion required for {http location} EBNF grammar?

2007-05-10T10:34:36Z

For the record, the WG resolved this issue [1] by accepting your proposal. I’ve just fixed it in the XML source. [2]

Since you were present, we know you agree with this resolution.

[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4550

[2] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-adjuncts.xml

Jonathan Marsh - http://www.wso2.com - http://auburnmarshes.spaces.live.com

From: www-ws-desc-request@... [mailto:www-ws-desc-request@...] On Behalf Of John Kaputin (gmail)
Sent: Tuesday, May 08, 2007 9:02 AM
To: WS-Description WG
Cc: woden-dev@...
Subject: Re: Is an assertion required for {http location} EBNF grammar?

I'd like to propose replacing the text associated with the EBNF grammar in section 6.8.1.1:

"The following EBNF [ISO/IEC 14977:1966] grammar represents the patterns for constructing the request IRI"

with the new assertion HTTPSerialization-2106:

"The {http location} property MUST conform to the following EBNF [ISO/IEC 14977:1966] grammar, which represents the patterns for constructing the request IRI."

regards,
John Kaputin.

On 5/4/07, John Kaputin (gmail) <jakaputin@...> wrote:

There is no WSDL assertion stating that an {http location} or whttp:location must conform to the EBNF grammar defined in Part 2 Section 6.8.1.1.

Consider the following whttp:location values, which do not conform to this EBNF grammar:

"/to}wn/{localname}" (unmatched left brace)
"/town/{local:name}" (template does not specify an NCName)
"/town/{localname" (closing right brace is missing)

Should these be considered WSDL errors? If so, should there be an assertion about the EBNF grammar? Apache Woden parses the whttp:location attribute and if it does not conform to the EBNF grammar the {http location} property is flagged as invalid, but there is no WSDL assertion to use for error reporting.

Alternatively, Woden could just ignore these grammar errors and treat them as ordinary string content in {http location} but the problem would still need to be resolved when the request IRI is constructed by the message builder.

John Kaputin.

Re: Issue responses

2007-05-10T10:32:14Z

Indeed.

Thanks,

JJ.

Jonathan Marsh wrote:

RE: small problems in part 1 appendix C

2007-05-10T10:31:00Z

Thank you for these issues. We tracked them as Issue 4492 [1] and Issue
4493 [2] in our short Last Call period. The Working Group added the
constraint "No xmlns() pointer part defines a namespace for the
targetNamespace of the WSDL 2.0 document" [3], and corrected the prefix as
requested [4].

Since you were present (IIRC) during the discussion, we assume you agree
with the resolution of these issues.

[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4492
[2] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4493
[3]
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html?content-
type=text/html;%20charset=utf-8#component-designator-canonical-form
[4]
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html?content-
type=text/html;%20charset=utf-8#Iri-ref-ex

Jonathan Marsh - http://www.wso2.com - http://auburnmarshes.spaces.live.com

> -----Original Message-----
> From: www-ws-desc-request@... [mailto:www-ws-desc-request@...] On
> Behalf Of Jacek Kopecky
> Sent: Wednesday, April 25, 2007 8:20 AM
> To: WS-Description WG
> Subject: small problems in part 1 appendix C
>
>
> Hi all,
>
> implementing the RDF mapping, I'm also implementing the creation of the
> fragment identifiers and I found the following small (maybe editorial)
> problems in Appendix C:
>
> 1) the canonical form does not say that no xmlns() pointer part should
> define the namespace same as the namespace of the WSDL 2.0 document, so
> it doesn't seem that the following would be uncanonical, while it
> should
> be:
> http://example.com/wsdl#
> xmlns(ns1=http://example.com/wsdl#)
> wsdl.interfaceFaultReference(iface/op/In/ns1:Foo)
>
> 2) example c-2 has a typo, it declares namespace prefix ns1 but uses
> xsTicketAgent in the fifth IRI
>
> Jacek

RE: Proposal to Include whttp:code to the output of the binding operation

2007-05-10T10:26:36Z

Thank you for this issue. We tracked it as Issue 4491 [1] in our short Last Call period. The Working Group was reluctant to add this new functionality at this late date (and is unsure that the benefits are clear). Accordingly it took no action on this issue.

The spec should be in Proposed Recommendation shortly, if you disagree with the resolution of this issue please inform us as soon as possible.

[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4491

Jonathan Marsh - http://www.wso2.com - http://auburnmarshes.spaces.live.com

From: www-ws-desc-request@... [mailto:www-ws-desc-request@...] On Behalf Of keith chapman
Sent: Sunday, April 22, 2007 11:01 PM
To: www-ws-desc
Subject: Proposal to Include whttp:code to the output of the binding operation

Hi all,

I wonder whteher its too late, but I think its import that it makes its way into the spec. I was playing around with APP trying to write a WSDL for it (Use it as a WSDL 2.0 demo). During this I came across a limitation which I guess WSDL 2.0 should address. The HTTPBinding allows a user to set a HTTP code on a fault but it does not allow a user to specify a http code on a response. This is a trick that we missed.

I would like to propose the inclusion of whttp:code property to the output of the binding operation. This will be critical for the HTTPBinding to be succesfull.

Thanks,
Keith.

--
Keith Chapman
WSO2 Inc.
Oxygen for Web Services Developers.
http://wso2.org/

Bug 4468 resolution

2007-05-10T10:23:46Z

This records that the WG closed your issue 4468 [1] as you suggested [2].

[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4468

[2] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-adjuncts.html?content-type=text/html;%20charset=utf-8#_http_request_iri_

Jonathan Marsh - http://www.wso2.com - http://auburnmarshes.spaces.live.com

RE: Comment on Web Services Description Language (WSDL) Version 2.0 Part 0: Primer

2007-05-10T10:20:59Z

Thank you for this issue. We tracked it as Issue 4427 [1] in our short Last Call period. The Working Group endeavored to correct all the bib references in all the specs [2,3,4,5,6].

The spec should be in Proposed Recommendation shortly, if you disagree with the resolution of this issue please inform us as soon as possible.

[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4457
[2] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-primer.html
[3] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html?content-type=text/html;%20charset=utf-8
[4] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-adjuncts.html?content-type=text/html;%20charset=utf-8
[5] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-soap11-binding.html?content-type=text/html;%20charset=utf-8
[6] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-rdf.html?content-type=text/html;%20charset=utf-8

Jonathan Marsh - http://www.wso2.com - http://auburnmarshes.spaces.live.com

> -----Original Message-----
> From: public-ws-desc-comments-request@... [mailto:public-ws-desc-
> comments-request@...] On Behalf Of Innovimax SARL
> Sent: Sunday, April 08, 2007 12:49 PM
> To: public-ws-desc-comments@...
> Subject: Comment on Web Services Description Language (WSDL) Version
> 2.0 Part 0: Primer
>
>
> Please find below listed a lot of errors in the References
>
> Please note also that errors could also be found in other part of the
> spec
> * WSDL 2.0 Core
> * WSDL 2.0 Adjuncts
> * WSDL 2.0 SOAP 1.1 Binding
> * WSDL 2.0 RDF Mapping
>
> Best regards,
>
> Mohamed ZERGAOUI
> Innovimax AC Rep
>
>
>
>
> In Web Services Description Language (WSDL) Version 2.0 Part 0: Primer
> W3C Working Draft 26 March 2007
> http://www.w3.org/TR/2007/WD-wsdl20-primer-20070326
>
> Normative Reference :
>
> "Key words for use in RFCs to Indicate Requirement Levels, S. Bradner,
> Author. Internet Engineering Task Force, March 1997. Available at
> http://www.ietf.org/rfc/rfc2119.txt."
> instead of
> "Key words for use in RFCs to Indicate Requirement Levels, S. Bradner,
> Author. Internet Engineering Task Force, June 1999. Available at
> http://www.ietf.org/rfc/rfc2119.txt."
>
> [[
> [IETF RFC 3023]
> XML Media Types", M. Murata, S. St. Laurent, D. Kohn, Authors.
> Internet Engineering Task Force, January 2001. Available at
> http://www.ietf.org/rfc/rfc3023.txt.
> ]]
> instead of
> [[
> [RFC 3023]
> IETF "RFC 3023: XML Media Types", M. Murata, S. St. Laurent, D.
> Kohn, July 1998.(Seehttp://www.ietf.org/rfc/rfc3023.txt.)
> ]]
>
> XML (Fourth Edition) instead of (third)
> Namespaces in XML 1.0 (Second Edition) instead of Namespace in XML
> XML Schema Part 1: Structures Second Edition instead of XML Schema
> Part 1: Structure
> XML Schema Part 2: Datatypes Second Edition instead of XML Schema Part
> 2: Datatypes
>
> In Informative Reference
>
> "XPointer Framework, Paul Grosso, Eve Maler, Jonathan Marsh, Norman
> Walsh, Editors. World Wide Web Consortium, 25 March 2003"
> instead of
> "XPointer Framework,Paul Grosso, Eve Maler, Jonathan Marsh, Norman
> Walsh, Editors. World Wide Web Consortium, 22 November 2002."
>
> "XML Schema Versioning Use Cases, Hoylen Sue. W3C XML Schema Working
> Group Draft, 31 January 2006. Available at
> http://www.w3.org/XML/2005/xsd-versioning-use-cases/"
> instead of
> "XML Schema Versioning Use Cases , Hoylen Sue. W3C XML Schema Working
> Group Draft, 15 April 2005. Available at
> http://www.w3.org/XML/2005/xsd-versioning-use-cases/"
>
> --
> Innovimax SARL
> Consulting, Training & XML Development
> 9, impasse des Orteaux
> 75020 Paris
> Tel : +33 8 72 475787
> Fax : +33 1 4356 1746
> http://www.innovimax.fr
> RCS Paris 488.018.631
> SARL au capital de 10.000 €

Issue responses

2007-05-10T10:17:35Z

This records that the WG treated your comments at [1] as issues 4412-4436 [2,3,4,5,6,7,8,9,10,11,12,13,14,15].

As you were present during most of these discussions, we assume the resolutions are acceptable to you as recorded.

[1] http://lists.w3.org/Archives/Member/w3c-ws-desc/2007Mar/0009

[2] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4423

[3] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4424

[4] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4425

[5] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4426

[6] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4427

[7] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4428

[8] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4429

[9] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4430

[10] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4431

[11] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4432

[12] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4433

[13] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4434

[14] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4435

[15] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4436

Jonathan Marsh - http://www.wso2.com - http://auburnmarshes.spaces.live.com

RE: Editorial Issues - Part 1

2007-05-10T10:11:12Z

Thank you for this issue. We tracked it as Issue 4421 [1] in our short Last Call period. The Working Group renamed section 1.1 to “Web Service” to “Service Description” [2], fixed the incorrect prefix in 1.4.5 [3], and changed “At the abstract level” to “At a high level” [4].

The spec should be in Proposed Recommendation shortly, if you disagree with the resolution of this issue please inform us as soon as possible.

[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4421

[2] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html?content-type=text/html;%20charset=utf-8#intro_ws

[3] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html?content-type=text/html;%20charset=utf-8#terminology

[4] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html?content-type=text/html;%20charset=utf-8#Description_details

Jonathan Marsh - http://www.wso2.com - http://auburnmarshes.spaces.live.com

From: www-ws-desc-request@... [mailto:www-ws-desc-request@...] On Behalf Of Ramkumar Menon
Sent: Friday, March 16, 2007 10:23 AM
To: www-ws-desc
Subject: Editorial Issues - Part 1

Gurus,

Please find the following editorial issues that I find in Part 1.

1) Why is 1.1 titled "Web Service" ? It does not describe what a Web Service is. It describes in summary on how WSDL describes a Web Service. Perhaps it should be titled "Service Description" or something on those lines
.
2) 1.4.5 --> Inlined Schema
statement - "An XML schema that is defined in the xs:types element information item of a WSDL 2.0 description."

suggestion - It should be "wsdl:types" and not "xs:types".

3) Section 2.1.1

Statement in the spec :- "At the abstract level, the Description component is just a container for two categories of components: WSDL 2.0 components and type system components.WSDL 2.0 components are interfaces, bindings and services. ".

Suggestion :- This gives a message that bindings and services exist at the abstract level. Is it true ? Moreover, the first sentence seems to suggest that the later part of the section will go and quote the Description component at the concrete level - which is missing .

--
Shift to the left, shift to the right!
Pop up, push down, byte, byte, byte!

-Ramkumar Menon
A typical Macroprocessor

RE: Proposal for Binding-0055 and Binding-1207001

2007-05-10T10:03:03Z

Thank you for this issue. We tracked it as Issue 4381 [1] in our short Last Call period. The Working Group preferred your alternative 2, and implemented that [2].

The spec should be in Proposed Recommendation shortly, if you disagree with the resolution of this issue please inform us as soon as possible.

[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4381

[2] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20.html?content-type=text/html;%20charset=utf-8#Binding-1047

Jonathan Marsh - http://www.wso2.com - http://auburnmarshes.spaces.live.com

From: www-ws-desc-request@... [mailto:www-ws-desc-request@...] On Behalf Of Ramkumar Menon
Sent: Friday, February 23, 2007 3:11 PM
To: www-ws-desc@...
Subject: Proposal for Binding-0055 and Binding-1207001

Gurus,

Binding-0055 states "A Binding component that defines bindings for an Interface component MUST define bindings for all the operations and faults of that Interface component."

Binding-1207001 states "A Binding component that defines bindings for an Interface component MUST define bindings for all the faults of that Interface component that are referenced from any of the operations in that Interface component."

I think Binding-0055 is not completely valid, since the Binding only needs to define bindings for faults in the interface component that are actually referenced in one of the interface operations.

I suggest two alternatives.

Alternative 1 - Combine the two assertions into a new Assertion.

i.e. an assertion that states

"A Binding component that defines bindings for an Interface component MUST define bindings for all the operations of that Interface component and all faults of that Interface component that are referenced from any of the operations in that Interface component."

Alternative 2 - Alter Binding-0055 to remove the portion relating to faults.

i.e. have Binding-0055 state as follows.
"A Binding component that defines bindings for an Interface component MUST define bindings for all the operations of that Interface component."

HTH,

Ram
--
Shift to the left, shift to the right!
Pop up, push down, byte, byte, byte!

-Ramkumar Menon
A typical Macroprocessor

RE: Proposal for Assertion InterfaceMessageReference-0042

2007-05-10T09:59:27Z

Thank you for this issue. We tracked it as Issue 4380 [1] in our short Last Call period. The Working Group closed it without action as the specification of a uniqueness constraint would prevent the attribute from being optional as it is now.

The spec should be in Proposed Recommendation shortly, if you disagree with the resolution of this issue please inform us as soon as possible.

[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4380

Jonathan Marsh - http://www.wso2.com - http://auburnmarshes.spaces.live.com

From: www-ws-desc-request@... [mailto:www-ws-desc-request@...] On Behalf Of Ramkumar Menon
Sent: Thursday, February 15, 2007 2:06 PM
To: www-ws-desc@...
Subject: Proposal for Assertion InterfaceMessageReference-0042

Hi Gurus,

The mentioned assertion states "For each Interface Message Reference component in the {interface message references} property of an Interface Operation component, its {message label} property MUST be unique.".

Correct me if I am wrong, but can we have the XSD capture this constraint explicitly ?

For instance,

<xs:element name="operation" type="wsdl:BindingOperationType">
<xs:unique name="messageLabel">
    <xs:selector xpath="(wsdl:input|wsdl:output:wsdl:infault|wsdl:outfault)">
     <xs:field xpath="@messageLabel">
    </xs:selectpr>
</xs:unique>
</xs:element>

rgds,

Ram
--
Shift to the left, shift to the right!
Pop up, push down, byte, byte, byte!

-Ramkumar Menon
A typical Macroprocessor

Re: Multiple whttp:inputSerialization

2007-04-24T09:06:15Z

Jonathan,

Thanks for your reply. I'll take your reply regarding the extension path
to support application/sparql-query to the DAWG and see if it suits our
needs. I'm ok with your resolution to not solve this at this stage in
your timeline and would support you moving to PR.

Elias Torres
DAWG (IBM)

Jonathan Marsh wrote:

> WSDL 2.0 only supports three kinds of serialization for XML data (e.g.
> described by an XML schema language and therefore with a content model of
> #any or #element): application/x-www-form-urlencoded, multipart/formdata,
> and application/xml and it's compatible media types.
>
> Unknown media types such as application/sparql-query aren't directly
> supported - although by defaulting unknown media types that are compatible
> with application/xml are. E.g. application/wsdl+xml would be serialized as
> application/xml.
>
> So, how would you describe the serialization of application/sparql-query? I
> assume you want to continue to support application/x-www-form-urlencoded, so
> you aren't likely to switch out the whole XML-based type system in favor of
> something else (even if you were there is no guarantee of interoperability -
> the spec leaves open the serialization in this case). That just leaves
> extension as the only way to change the behavior that you seek. For
> instance you could define an extension as follows:
>
> <wsdl:binding ...>
> <sparql-extension:support-sparql-query-media-type wsdl:required="true"/>
> <wsdl:operation ...
> whttp:inputSerialization="application/x-www-form-urlencoded,
> application/sparql-query">
>
> Processors that understood it would be able to correctly serialize the
> message using whatever rules you defined, and other processors would have
> adequate warning that they would not understand how to process the
> operation. The spec for such an extension would indicate the precise
> details of serialization, including which parameters are serialized in the
> URL and how the body is constructed, as well as some formalisms such as how
> the component model is affected (probably just add a Boolean {supports
> sparql-query media type} property).
>
> I had opened a bug [1] on this issue during our return to Last Call. Since
> there isn't anything that appears to be fixable at this late date in WSDL
> 2.0 the WG voted to close the bug without any action. If this resolution
> isn't acceptable please let us know within a week - at that time we expect
> to move to PR.
>
> [1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4458
>
>
> Jonathan Marsh - http://www.wso2.com - http://auburnmarshes.spaces.live.com
>
>> -----Original Message-----
>> From: public-ws-desc-comments-request@... [mailto:public-ws-desc-
>> comments-request@...] On Behalf Of Elias Torres
>> Sent: Friday, March 30, 2007 11:51 AM
>> To: public-ws-desc-comments@...
>> Subject: Re: Multiple whttp:inputSerialization
>>
>>
>> Let me be a bit more specific of what we are trying to describe using
>> WSDL.
>>
>> Currently we support x-www-form-urlencoded:
>>
>> POST /sparql/ HTTP/1.1
>> Host: www.example
>> User-agent: my-sparql-client/0.1
>> Content-type: application/x-www-form-urlencoded
>>
>> query=SELECT...&default-graph-uri=A&named-graph-uri=B
>>
>> But we would also like the following:
>>
>> POST /sparql/?default-graph-uri=A&named-graph-uri=B HTTP/1.1
>> Host: www.example
>> User-agent: my-sparql-client/0.1
>> Content-type: application/sparql-query
>>
>> SELECT ?s ?p ?o
>>
>> Basically, although some folks believe it would be nice to have the
>> ability to POST application/sparql-query documents, we still need the
>> ability to specify default-graph-uri, named-graph-uri and so on. The
>> only way to do that would be to specify it in the URI, but I'm sure
>> that
>> this will be stretching WSDL a bit. Please let us know if this is
>> sensible or not, so we can proceed to notify our commenter the results
>> of our investigation.
>>
>> Sincerely,
>>
>> Elias
>>
>>
>
>
>

RE: Multiple whttp:inputSerialization

2007-04-19T11:15:22Z

WSDL 2.0 only supports three kinds of serialization for XML data (e.g.
described by an XML schema language and therefore with a content model of
#any or #element): application/x-www-form-urlencoded, multipart/formdata,
and application/xml and it's compatible media types.

Unknown media types such as application/sparql-query aren't directly
supported - although by defaulting unknown media types that are compatible
with application/xml are. E.g. application/wsdl+xml would be serialized as
application/xml.

So, how would you describe the serialization of application/sparql-query? I
assume you want to continue to support application/x-www-form-urlencoded, so
you aren't likely to switch out the whole XML-based type system in favor of
something else (even if you were there is no guarantee of interoperability -
the spec leaves open the serialization in this case). That just leaves
extension as the only way to change the behavior that you seek. For
instance you could define an extension as follows:

<wsdl:binding ...>
<sparql-extension:support-sparql-query-media-type wsdl:required="true"/>
<wsdl:operation ...
whttp:inputSerialization="application/x-www-form-urlencoded,
application/sparql-query">

Processors that understood it would be able to correctly serialize the
message using whatever rules you defined, and other processors would have
adequate warning that they would not understand how to process the
operation. The spec for such an extension would indicate the precise
details of serialization, including which parameters are serialized in the
URL and how the body is constructed, as well as some formalisms such as how
the component model is affected (probably just add a Boolean {supports
sparql-query media type} property).

I had opened a bug [1] on this issue during our return to Last Call. Since
there isn't anything that appears to be fixable at this late date in WSDL
2.0 the WG voted to close the bug without any action. If this resolution
isn't acceptable please let us know within a week - at that time we expect
to move to PR.

[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=4458

Jonathan Marsh - http://www.wso2.com - http://auburnmarshes.spaces.live.com

> -----Original Message-----
> From: public-ws-desc-comments-request@... [mailto:public-ws-desc-
> comments-request@...] On Behalf Of Elias Torres
> Sent: Friday, March 30, 2007 11:51 AM
> To: public-ws-desc-comments@...
> Subject: Re: Multiple whttp:inputSerialization
>
>
> Let me be a bit more specific of what we are trying to describe using
> WSDL.
>
> Currently we support x-www-form-urlencoded:
>
> POST /sparql/ HTTP/1.1
> Host: www.example
> User-agent: my-sparql-client/0.1
> Content-type: application/x-www-form-urlencoded
>
> query=SELECT...&default-graph-uri=A&named-graph-uri=B
>
> But we would also like the following:
>
> POST /sparql/?default-graph-uri=A&named-graph-uri=B HTTP/1.1
> Host: www.example
> User-agent: my-sparql-client/0.1
> Content-type: application/sparql-query
>
> SELECT ?s ?p ?o
>
> Basically, although some folks believe it would be nice to have the
> ability to POST application/sparql-query documents, we still need the
> ability to specify default-graph-uri, named-graph-uri and so on. The
> only way to do that would be to specify it in the URI, but I'm sure
> that
> this will be stretching WSDL a bit. Please let us know if this is
> sensible or not, so we can proceed to notify our commenter the results
> of our investigation.
>
> Sincerely,
>
> Elias
>
>

Comment on Web Services Description Language (WSDL) Version 2.0 Part 0: Primer

2007-04-08T13:49:10Z

Please find below listed a lot of errors in the References

Please note also that errors could also be found in other part of the spec
* WSDL 2.0 Core
* WSDL 2.0 Adjuncts
* WSDL 2.0 SOAP 1.1 Binding
* WSDL 2.0 RDF Mapping

Best regards,

Mohamed ZERGAOUI
Innovimax AC Rep

In Web Services Description Language (WSDL) Version 2.0 Part 0: Primer
W3C Working Draft 26 March 2007
http://www.w3.org/TR/2007/WD-wsdl20-primer-20070326

Normative Reference :

"Key words for use in RFCs to Indicate Requirement Levels, S. Bradner,
Author. Internet Engineering Task Force, March 1997. Available at
http://www.ietf.org/rfc/rfc2119.txt."
instead of
"Key words for use in RFCs to Indicate Requirement Levels, S. Bradner,
Author. Internet Engineering Task Force, June 1999. Available at
http://www.ietf.org/rfc/rfc2119.txt."

[[
[IETF RFC 3023]
XML Media Types", M. Murata, S. St. Laurent, D. Kohn, Authors.
Internet Engineering Task Force, January 2001. Available at
http://www.ietf.org/rfc/rfc3023.txt.
]]
instead of
[[
[RFC 3023]
IETF "RFC 3023: XML Media Types", M. Murata, S. St. Laurent, D.
Kohn, July 1998.(Seehttp://www.ietf.org/rfc/rfc3023.txt.)
]]

XML (Fourth Edition) instead of (third)
Namespaces in XML 1.0 (Second Edition) instead of Namespace in XML
XML Schema Part 1: Structures Second Edition instead of XML Schema
Part 1: Structure
XML Schema Part 2: Datatypes Second Edition instead of XML Schema Part
2: Datatypes

In Informative Reference

"XPointer Framework, Paul Grosso, Eve Maler, Jonathan Marsh, Norman
Walsh, Editors. World Wide Web Consortium, 25 March 2003"
instead of
"XPointer Framework,Paul Grosso, Eve Maler, Jonathan Marsh, Norman
Walsh, Editors. World Wide Web Consortium, 22 November 2002."

"XML Schema Versioning Use Cases, Hoylen Sue. W3C XML Schema Working
Group Draft, 31 January 2006. Available at
http://www.w3.org/XML/2005/xsd-versioning-use-cases/"
instead of
"XML Schema Versioning Use Cases , Hoylen Sue. W3C XML Schema Working
Group Draft, 15 April 2005. Available at
http://www.w3.org/XML/2005/xsd-versioning-use-cases/"

--
Innovimax SARL
Consulting, Training & XML Development
9, impasse des Orteaux
75020 Paris
Tel : +33 8 72 475787
Fax : +33 1 4356 1746
http://www.innovimax.fr
RCS Paris 488.018.631
SARL au capital de 10.000 €

Re: Multiple whttp:inputSerialization

2007-03-30T12:50:35Z

Let me be a bit more specific of what we are trying to describe using WSDL.

Currently we support x-www-form-urlencoded:

POST /sparql/ HTTP/1.1
Host: www.example
User-agent: my-sparql-client/0.1
Content-type: application/x-www-form-urlencoded

query=SELECT...&default-graph-uri=A&named-graph-uri=B

But we would also like the following:

POST /sparql/?default-graph-uri=A&named-graph-uri=B HTTP/1.1
Host: www.example
User-agent: my-sparql-client/0.1
Content-type: application/sparql-query

SELECT ?s ?p ?o

Basically, although some folks believe it would be nice to have the
ability to POST application/sparql-query documents, we still need the
ability to specify default-graph-uri, named-graph-uri and so on. The
only way to do that would be to specify it in the URI, but I'm sure that
this will be stretching WSDL a bit. Please let us know if this is
sensible or not, so we can proceed to notify our commenter the results
of our investigation.

Sincerely,

Elias

Multiple whttp:inputSerialization

2007-03-30T11:25:43Z

Dear WG,

I'm currently one of the SPARQL protocol editors and we have received a
request [1] to add support for an additional input serialization and am
seeking your advice. We have done a review of the current documents [2] to
see if this is possible but we were unable to come up with a solution and
are hoping you can help us. Ideally, we would like to know how to add
support for both application/x-www-form-urlencoded and
application/sparql-query in our query operation [3].

Additionally, my colleague Lee Feigenbaum believes we also support an XML
version of our x-www-form-urlencoded data by virtue of our WSDL defining
the input message parts via a reference to an XML schema element (<input
... element="st:query-request"/>), the query message has a message content
model of "element". Turning to:

6.3.2.1 Serialization rules for XML messages (
http://www.w3.org/TR/wsdl20-adjuncts/#_http_binding_default_rule_psf ), we
see that there are serialization rules given explicitly for
application/xml. These rules are at
http://www.w3.org/TR/wsdl20-adjuncts/#_http_operation_xml_encoding and say
that serializing a message as application/xml means that the message's
instance data is serialized as Canonical XML. Further, the instance data is
explicitly defined (
http://www.w3.org/TR/wsdl20-adjuncts/#instance_data ) to be "The internal
tree representation of an input...constrained by...the XML element
referenced in the {element declaration} property of the Interface Message
Reference component".

As I read it, this means that the inclusion of application/xml amongst our
inputSerialization allows for POSTed content that looks like:

<st:query-request>
<st:query>SELECT * WHERE { ... } </st:query>
<st:default-graph-uri>http://example.org/graph1</st:default-graph-uri>
<st:default-graph-uri>http://example.org/graph2</st:default-graph-uri>
<st:named-graph-uri>http://example.org/graph3</st:named-graph-uri>
</st:query-request>

However, we don't believe that this was our intention, furthermore, our
real interest is whether we can use multiple whttp:inputSerialization
values to add support for POSTing application/sparql-query documents.

Thanks,

Elias Torres on behalf of the DAWG.

[1]
http://lists.w3.org/Archives/Public/public-rdf-dawg-comments/2006Sep/0007
[2] http://lists.w3.org/Archives/Public/public-rdf-dawg/2007JanMar/0112
[3] http://www.w3.org/TR/rdf-sparql-protocol/sparql-protocol-query.wsdl
[4] http://www.w3.org/TR/rdf-sparql-protocol/sparql-protocol-types.xsd

RE: Query parameter separator value

2007-03-16T17:02:55Z

Thank you for this comment. The Working Group recorded this issue as a
CR156 [1].

The WG decided to restrict the values of the query parameter separator with
an assertion and a schema pattern. This has been incorporated into the
draft at [2].

[1] http://www.w3.org/2002/ws/desc/5/cr-issues/issues.html#CR156
[2]
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-adjuncts.xml#
http-operation-decl-xml

Jonathan Marsh - http://www.wso2.com - http://auburnmarshes.spaces.live.com

> -----Original Message-----
> From: www-ws-desc-request@... [mailto:www-ws-desc-request@...] On
> Behalf Of Youenn Fablet
> Sent: Wednesday, February 21, 2007 4:42 AM
> To: www-ws-desc
> Subject: Query parameter separator value
>
>
> Reading the specification, it seems that the only constraint on the
> separator value is to be a xml string of length 1.
> It would therefore be possible to have a separator value that needs to
> be %-encoded in the URL (e.g. queryParameterSeparator="é").
> I do not know whether that was intended but in this case, the query
> string may become ambiguous: if the separator value appears in a
> parameter value, it will be %-encoded exactly like the separator value.
> It might be safer to restrict the separator value range.
>
> In any case, the most sensible values are '&' and ';'. Is there any
> other obvious possibility?
> While '&' is the default value, ';' does not appear AFAIKT neither in
> the spec nor in the primer.
> It might therefore be good to add a statement that tells a word about
> these values, maybe as a SHOULD.
> Regards,
> Youenn
>

RE: LocationTemplate-1G test

2007-03-13T18:05:23Z

FTR, the Working Group this issue as a CR157 [1], and fixed it in the latest
editor's draft [2].

I agree with the resolution.

[1] http://www.w3.org/2002/ws/desc/5/cr-issues/issues.html#CR157
[2]
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-adjuncts.html
?content-type=text/html;%20charset=utf-8#_http_operation_location_cited_ser

Jonathan Marsh - http://www.wso2.com - http://auburnmarshes.spaces.live.com

> -----Original Message-----
> From: www-ws-desc-request@... [mailto:www-ws-desc-request@...] On
> Behalf Of Jonathan Marsh
> Sent: Thursday, February 22, 2007 2:01 PM
> To: 'Youenn Fablet'; 'keith chapman'
> Cc: 'www-ws-desc'
> Subject: RE: LocationTemplate-1G test
>
>
> Summarizing this thread, this morning's discussion, and the related
> issues:
>
> - [FIXED] * was improperly encoded in the baseline.
>
> - [QUESTION 1] The spec says what characters MUST be encoded, but there
> are
> also characters that MAY be encoded such as * (and pretty much any other
> character except %). Our test suite assumes only the characters that MUST
> be are. Should we change this? (I think we should do this
> opportunistically, that is, if a testcase is proven to be correct, we
> simply
> add an alternative that matches that implementation's encoding strategy.
> I
> don't think we have any failures because of this at present.)
>
> - [AGREED] Per the last paragraph of 6.8.1, referencing section 3.1 of RFC
> 3987, some further encoding is performed after the http location templates
> are resolved and combined with the {address} property.
>
> - [QUESTION 2] Is this sufficiently clear in the spec? (I think so.)
>
> - [AGREED] Besides the extended characters encoded above, the spec says
> implementations SHOULD also encode "<", ">", '"', space, "{", "}", "|",
> "\",
> "^", and "`". Our test suite will currently assume this SHOULD has been
> followed.
>
> - [FIXED] There other editorial improvements such as removing the double
> negative, reordering bullets, removing query parameter separator from
> consideration before the "?".
>
> - [QUESTION 3] Are there additional editorial improvements possible? (I
> think so, as reported in
> http://lists.w3.org/Archives/Public/www-ws-desc/2007Feb/0193.html).
>
> - [QUESTION 4] Is "&" a harmful character before the "?". If not, we
> should
> add it to the excluded list.
>
> - [QUESTION 5] Are ";" and "=" harmful characters before the "?". If so,
> we
> should remove them from the excluded list.
>
> I'll research proposals for 4 and 5 per my AI, but if there are any other
> questions I didn't capture here, let us know!
>
> Jonathan Marsh - http://www.wso2.com -
> http://auburnmarshes.spaces.live.com
>
>
> > -----Original Message-----
> > From: www-ws-desc-request@... [mailto:www-ws-desc-request@...] On
> > Behalf Of Youenn Fablet
> > Sent: Thursday, February 22, 2007 5:35 AM
> > To: keith chapman
> > Cc: www-ws-desc
> > Subject: Re: LocationTemplate-1G test
> >
> >
> > +1
> > If we have a location="?path={value1}&uri={value2}", the intent of the
> > specification is that '&' is sent as is in the url.
> > Some characters (the non-ascii ones for instance) must of course be
> > encoded to form a correct URL.
> > Some text may be missing in the specification to describe this
> precisely.
> > Youenn
> >
> >
> > keith chapman wrote:
> > > Even option 1 does not speak of encoding the httplocation. It only
> > > speaks of encoding instance data. This raises the issue, should the
> > > location template itself be encoded?
> > >
> > > If we say the location template itself will be encoded then the user
> > > wont hav an option of sending unencoded stuff in the url (unless
> > > through templating). But if we send it raw as it is then the user can
> > > do anything he wants.
> > >
> > > Thanks,
> > > Keith.
> > >
> > > On 2/22/07, *Jean-Jacques Moreau* <jean-jacques.moreau@...
> > > <mailto:jean-jacques.moreau@...>> wrote:
> > >
> > > Comments inline.
> > >
> > > keith chapman wrote:
> > > > See comments inline
> > > >
> > > > On 2/22/07, *Jonathan Marsh* < jonathan@...
> > > <mailto:jonathan@...>
> > > > <mailto:jonathan@... <mailto:jonathan@...>>> wrote:
> > > >
> > > > I thought so too a couple of days ago, but then I found this
> > in
> > > > 6.8.1.1 <http://6.8.1.1> <http://6.8.1.1>:
> > > >
> > > > * Percent-encoding MUST be performed using the UTF-8
> > > > representation of the character as prescribed by
> > > section 6.4
> > > > of [/ IETF RFC 3987
> > > >
> > >
> <http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/ws/desc/wsdl20/wsdl20-
> > adjuncts.html?content-type=text/html;%20charset=utf-8#RFC3987%23RFC3987
> > >
> <http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/ws/desc/wsdl20/wsdl20-
> > adjuncts.html?content-type=text/html;%20charset=utf-
> > 8#RFC3987%23RFC3987>>/].
> > > >
> > > > My understanding of this was that it specifies the encoding
> > > mechanism
> > > > to be used, when encoding is performed. I think wat it says is
> > that
> > > > instance data that is encoded should be encoded it in this way.
> It
> > > > does not say anything about encoding the httplocation itself.
> > > Yes, this is how the spec was meant to be interpreted (and how I
> > > understood the resolution to CR117). However, since the resolution
> > is
> > > Jonathan's option 1 [1] in the first place, we should probably do
> > > as he
> > > suggests.
> > >
> > > Jonathan, shall I go make this more explicit in the spec?
> > >
> > > JJ.
> > >
> > > [1]
> > > http://lists.w3.org/Archives/Public/www-ws-desc/2007Feb/0039.html
> > > <http://lists.w3.org/Archives/Public/www-ws-
> desc/2007Feb/0039.html>
> > > >
> > > > Section 6.4 is where I got the list of characters to be
> > > encoded in
> > > > my earlier mail.
> > > >
> > > >
> > > >
> > > > I actually do think we should be encoding characters in the
> > > > template before we stick it in a message that takes a URI
> > > (if the
> > > > message were to take an IRI that would be different, but
> AIUI
> > a
> > > > URI goes in the message in SOAP/HTTP).
> > > >
> > > >
> > > >
> > > > **Jonathan Marsh** - http://www.wso2.com
> <http://www.wso2.com>
> > -
> > > > http://auburnmarshes.spaces.live.com
> > > >
> > > >
> > > >
> > > >
> > > ------------------------------------------------------------------
> --
> > ----
> > > >
> > > > *From:* keith chapman [mailto:keithgchapman@...
> > > <mailto:keithgchapman@...>
> > > > <mailto:keithgchapman@...
> > > <mailto:keithgchapman@...>>]
> > > > *Sent:* Wednesday, February 21, 2007 9:03 PM
> > > > *To:* Jonathan Marsh
> > > > *Cc:* Youenn Fablet; www-ws-desc
> > > >
> > > > *Subject:* Re: LocationTemplate-1G test
> > > >
> > > >
> > > >
> > > > Hi Jonathan and all,
> > > >
> > > > Section 6.8.1.1 <http://6.8.1.1> <http://6.8.1.1> [1] in
> > > adjuncts does not speak of
> > > > encoding characters from the httpLocation it self. As I
> > > understood
> > > > encoding is performed ONLY on the instance data which
> replaces
> > > > templates. In that case I dont think that {{4(^$@!}}4^@*}}
> > [2]
> > > > should be encoded. Afterall its the arthor of the web
> > > services who
> > > > sticks in the httpLocation. May be he wanted to send those
> > > > characters as it is in the URL. He should be aware of it. I
> > dont
> > > > think that we should be encoding the characters in the
> > template.
> > > >
> > > > Should we make this clear in the spec or have
> > > I misunderstood it?
> > > >
> > > > [1]
> > > >
> > > http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl20/wsdl20-
> > adjuncts.html?content-type=text/html;%20charset=utf-
> > 8#_http_operation_location_cited_ser
> > >
> <http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/ws/desc/wsdl20/wsdl20-
> > adjuncts.html?content-type=text/html;%20charset=utf-
> > 8#_http_operation_location_cited_ser>
> > > >
> > >
> <http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/ws/desc/wsdl20/wsdl20-
> > adjuncts.html?content-type=text/html;%20charset=utf-
> > 8#_http_operation_location_cited_ser
> > >
> <http://dev.w3.org/cvsweb/%7Echeckout%7E/2002/ws/desc/wsdl20/wsdl20-
> > adjuncts.html?content-type=text/html;%20charset=utf-
> > 8#_http_operation_location_cited_ser>>
> > > >
> > > > [2] datespace/{year}.html?passphrase={time}{{4(^$@!}}4^@*}}
> > > >
> > > > Thanks,
> > > > Keith.
> > > >
> > > > On 2/21/07, *Jonathan Marsh* < jonathan@...
> > > <mailto:jonathan@...>
> > > > <mailto:jonathan@... <mailto:jonathan@...>>>
> wrote:
> > > >
> > > > I looked into message 13 there. The location template in
> that
> > > > testcase is:
> > > >
> > > > datespace/{year}.html?passphrase={time}{{4(^$@!}}4^@*}}
> > > >
> > > > This testcase test not only that templates are encoded, but
> > that
> > > > the IRI is
> > > > correctly converted to a URI per RFC3987. Many characters
> > over
> > > > #xA0 are
> > > > %-encoded, as well as "<", ">", '"', space, "{", "}", "|",
> > "\",
> > > > "^", and
> > > > "`".
> > > >
> > > >
> > datespace/2006.html?passphrase=16:40:00%7B4(%5E$@!%7D4%5E@*%7D
> > > >
> > > > Indeed the "*" should have been omitted from the list of
> > > > characters encoded
> > > > during this conversion. I've updated the expected results,
> > > > putting Canon at
> > > > all green on this testcase. Axis2 still fails the testcase
> > > because it
> > > > doesn't seem to be doing the encoding listed above at all.
> > > >
> > > > Jonathan Marsh - http://www.wso2.com -
> > > > http://auburnmarshes.spaces.live.com
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Youenn Fablet [mailto: youenn.fablet@...
> > > <mailto:youenn.fablet@...>
> > > > <mailto:youenn.fablet@...
> > > <mailto:youenn.fablet@...>>]
> > > > > Sent: Tuesday, February 20, 2007 5:31 AM
> > > > > To: keith chapman
> > > > > Cc: www-ws-desc; Jonathan Marsh
> > > > > Subject: Re: LocationTemplate-1G test
> > > > >
> > > > > Here is canon location template 1G result.
> > > > > There is one red (request 13).
> > > > > It seems that our implementation is not %-encoding the '*'
> > > character
> > > > > while the test framework wants it to be %-encoded.
> > > > > As per the current draft, '*' is not in the
> > > must-be-encoded set.
> > > > > An application may therefore typically choose to %-encode
> > > it or not,
> > > > > right?
> > > > > The test framework should only check that must-be-%-
> encoded
> > > > characters
> > > > > are correctly encoded and nothing more.
> > > > > I do not know whether this is easily feasible in the
> > > current test
> > > > > framework though.
> > > > > Youenn
> > > > >
> > > > > keith chapman wrote:
> > > > > >
> > > > > > Hi Jonathan,
> > > > > >
> > > > > > Request 11 shows red due to a mistake in the test
> > > framework. You
> > > > > > forgot to add 000Z to one time element...
> > > > > >
> > > > > > Thanks,
> > > > > > Keith.
> > > > > > --
> > > > > > Keith Chapman
> > > > > > WSO2 Inc.
> > > > > > Oxygen for Web Services Developers.
> > > > > > http://wso2.org/
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Keith Chapman
> > > > WSO2 Inc.
> > > > Oxygen for Web Services Developers.
> > > > http://wso2.org/ <http://wso2.org/>
> > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Keith Chapman
> > > > WSO2 Inc.
> > > > Oxygen for Web Services Developers.
> > > > http://wso2.org/
> > >
> > >
> > >
> > >
> > > --
> > > Keith Chapman
> > > WSO2 Inc.
> > > Oxygen for Web Services Developers.
> > > http://wso2.org/
>