W3C home > Mailing lists > Public > www-ws-desc@w3.org > November 2003

RE: Revisiting WSDL Compontent Designators

From: David Orchard <dorchard@bea.com>
Date: Thu, 13 Nov 2003 09:02:59 -0800
To: "'Sedukhin, Igor S'" <Igor.Sedukhin@ca.com>, "'Jonathan Marsh'" <jmarsh@microsoft.com>, <www-ws-desc@w3.org>
Message-ID: <032401c3aa07$fdd31cf0$6401a8c0@beasys.com>
I agree that this has some troubling aspects.  However, I'd guess that one
of the reason why XML schema doesn't recommend the schema doc available at
the ns is that schema didn't define a media type with a fragment identifier
for it's component references.  The component designators for schema aren't
part of the language...

It's hard to reconcile the many different requirements together.

Dave

> -----Original Message-----
> From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org]On
> Behalf Of Sedukhin, Igor S
> Sent: Thursday, November 13, 2003 8:23 AM
> To: Jonathan Marsh; www-ws-desc@w3.org
> Subject: RE: Revisiting WSDL Compontent Designators
> 
> 
> 
> +1
> 
> 4) [at the end] is questionable though. Isn't targetNamespace 
> supposed to define 'where' the WSDL components are defined 
> (belong to)? It was also supposed to identify semantics of 
> the described thingies. I don't think that XML Schema 
> recommends that schema document itself is available at the 
> targetNamespace.
> 
> 
> -- Igor Sedukhin .. (igor.sedukhin@ca.com)
> -- (631) 342-4325 .. 1 CA Plaza, Islandia, NY 11788
> 
> -----Original Message-----
> From: www-ws-desc-request@w3.org 
> [mailto:www-ws-desc-request@w3.org] On Behalf Of Jonathan Marsh
> Sent: Tuesday, November 11, 2003 2:54 PM
> To: www-ws-desc@w3.org
> Subject: Revisiting WSDL Compontent Designators
> 
> 
> I'm reviewing the draft TAG finding at
> http://www.w3.org/2001/tag/doc/abstractComponentRefs-20031030.
>   Here are some thoughts:
> 
> 1) The finding states that using a namespace name for the 
> base of the identifier is OK (although it does not 
> unambiguously recommend this
> practice.)
> 
> 2) The finding states that instances of the description 
> language should be available by de-referencing the identifier 
> - this implies that WSDL should recommend that a WSDL 
> document be available at the targetNamespace URI and that the 
> WSDL media type registration include the fragment syntax we agree on.
> 
> 3) The finding communicates the feeling that some TAG members 
> have that an XPointer-compatible syntax not be used.  
> Following the minutes of the discussion, this appears to be 
> motivated by a belief that unescaped parentheses are not 
> allowed in fragments.  But from
> http://www.rfc-editor.org/rfc/rfc2396.txt:
> 
>       fragment      = *uric
>       uric          = reserved | unreserved | escaped
>       unreserved    = alphanum | mark
>       mark          = "-" | "_" | "." | "!" | "~" | "*" | "'" |
>                       "(" | ")"
> 
> Which clearly shows that parens are allowed (and not even 
> reserved).  I conclude that this is just a momentary lapse 
> that the TAG will rectify soon.  I think our 
> XPointer-compatible syntax is good.
> 
> I also notice that certain names may not be expressible in "alphanum"
> and so we may need to require %-escaping of some characters 
> (assuming we want a single URI- (not IRI-) compatible string 
> as an identifier.
> 
> 
> Proposal
> 
> I therefore propose that we adopt the TAG finding (except for 
> the missing parens):
> 
> 1) Reintroduce WSDL component designators as an appendix in 
> our specification (see 
http://www.w3.org/TR/2003/WD-wsdl12-20030611/#wsdl-uri-references),
cleaning up the text to remove the issues and rationale and instead just
present our solution.

2) Add a clause to the appendix providing a rule for escaping characters in
component names not allowed in URIs (e.g. name characters other than
alphanum must be %-escaped using UTF-8 byte values).

3) Reintroduce these fragment identifiers as a normative part of the
media-type registration.

4) Add a statement recommending to authors to make WSDL available at the
targetNamespace.





Received on Thursday, 13 November 2003 12:04:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:58:27 GMT