LC80: frag id extensions for wsoap:header, whttp:header, wsoap:module

As per my action item, I have been thinking about defining fragment
identifiers for the modules that we define in Part 2.

However, the following issue crossed my mind: in order to have
meaningful fragment identifiers, they need to be defined for a
particular Internet media type. This is what we are doing in Part 1
for application/wsdl+xml.

However, Part 2 defines extensions of WSDL 2.0, and other specs will
be defining similar extensions that may in turn define WSDL 2.0
components and that will need a fragment identifier.

We will not be able to define all those fragment identifiers in our
application/wsdl+xml media type declaration in Part 1.

I see three ways forward:

1. change the way we build our URI references; e.g. have an XPointer
   syntax that is generic enough that we can use it in an extensible
   way:

   e.g.
   
   http://example.org/TicketAgent.wsdl20#wsdl.interface(TicketAgent)
   http://example.org/TicketAgent.wsdl20#wsdl.feature(wsdl.interface(TicketAgent)/http://example.com/secure-channel)

   could become:

   http://example.org/TicketAgent.wsdl20#wsdl.id(interface(TicketAgent))
   http://example.org/TicketAgent.wsdl20#wsdl.id(feature(wsdl.interface(TicketAgent)/http://example.com/secure-channel))

   i.e.:

   http://example.org/TicketAgent.wsdl20#wsdl.id(<whatever>)

2. keep the current syntax, but add an extensibility point for
   extensions:

   http://example.org/TicketAgent.wsdl20#wsdl.extension(<whatever>)

3. keep the status quo and not allow for extension components to be
   identified with a URI.

1 is more symmetrical than 2, but I don't think that I have a real
preference between them. 3 seems to go against our requirement R120.

However, considering the first two solutions, it seems that this
brings additional issues on the table: if I find something I don't
know in either #wsdl.id() or #wsdl.extension(), how do I know what
this means? We would probably need to have some rules for defining
identifiers, and have some text about when you get something you don't
know. This is similar to XPointer schemes: we're defining such a
scheme, and people may define additional syntax for it.

Now, with such a mechanism, identifying the components defined in Part
2 could be done with the following syntax:

• wsoap:header: <whatever> = wsoap.header(parent/element)

  with:
  - parent: Pointer Part
  - element: {element} QName serialized as <namespace URI>#<local name>

  Example:
  - Proposal 1:
    http://example.org/TicketAgent.wsdl21#wsdl.id(wsoap.header(bindingFault(mybinding/myfault)/http://example.org/myns#foo))
  - Proposal 2:
    http://example.org/TicketAgent.wsdl20#wsdl.extension(wsoap.header(wsdl.bindingFault(mybinding/myfault)/http://example.org/myns#foo))

• whttp:header: same as wsoap:header

• wsoap:module: <whatever> = wsoap.module(parent/uri)

  with:
  - parent: Pointer Part
  - element: {uri} URI (now IRI)

I am afraid that the syntax for extensions is starting to be fairly
complex, with 3 levels of parenthesis.

Cheers,

Hugo

-- 
Hugo Haas - W3C
mailto:hugo@w3.org - http://www.w3.org/People/Hugo/