Re: [wsbpel-spec-edit] Re: URIs for RDDLs, WSDLs, Schemas, etc

[Robin Cover <robin@oasis-open.org>]

On Wed, 16 Aug 2006, Alex Yiu wrote:
>
> Hi Robin,
>
> (BTW, I work in OracleJSP engine for a number of years, before starting
> doing BPEL work. Hence, I have some basic knowledge on Apache
> integration and includiing its mod.)

Excellent... you're in a great position to advise us, then, as OASIS
staff attempts to identify optimal solutions using the Apache
server directives.  That's a moot point for the moment: the IT staff
needs to unravel some configuration dependencies, maybe upgrade from
Apache 1.3 to Apache 2.x, and then implement real solutions to replace
our current adhocery.  Meantime, we are stuck with Apache default
behaviors (Apache 1.3).

>
> *[a]*
> Just to clarify:
> I guess WS-RX is using a handcraft "index.html" that has a META HTML
> refresh tag to perform the redirect, instead of mod_rewrite or mod_alias
> in Apache. And, META HTML refresh tag is not preferred for some reason.
>
> Is my understanding correct so far?

Yes. The redirect as implemented creates too much traffic, confuses
some pieces of software, and has the undesirable effect of populating
the browser address window with the URI for the RDDL document
instead of retaining the NS URI.

What we want (per some discussions with our web architecture experts)
is more akin to what one observes in connection with NS URIs and
RDDLs as used by W3C and the (WS-*) xmlsoap.org web sites.

Contrast (A) the behavior exhibited in connection with these NS URIs

- http://www.w3.org/2000/svg
- http://schemas.xmlsoap.org/ws/2004/09/transfer
- http://www.w3.org/2003/05/soap-envelope
- http://www.opengis.net/gml

[the NS URI or the related directory URI remain visible in the
browser address window when the NS URI is dereferenced]

with (B) at WS-RX TC web site:

http://docs.oasis-open.org/ws-rx/wsrm/200510

/* when dereferenced, repopulates address window with  */

http://docs.oasis-open.org/ws-rx/wsrm/200510/wsrm-1.1-rddl-cd-02.html

We think "(A)" is what users expect, not "(B)". The RDDL is designed
for humans as well as machines, but when humans are looking for
information about a namespace (URI) via a namespace document, it
seems far preferable to have the namespace URI displayed in the
window when the human user is viewing the RDDL information.  We
intend, provisionally, to recommend a solution that resembles
the behavior for this NS URI:

   http://www.w3.org/2000/svg

>
> *[b]*
> Questions:
> Would it be more acceptable that the "index.html" itself located in a
> number directory is the XHTML+RDDL content? (i.e. no meta html refresh
> or redirect business)

I can understand why you'd propose that, and arguably it's more
acceptable than what we now implement for WS-RX (wsrm).

On the other hand, one of the key design goals for the OASIS Open
Library (http://docs.oasis-open.org/) is to make the file system
contents transparent to users. That goal is motivated by several
features we want to implement, like "please ZIP up the contents
of this directory (recursively) and let me download the whole
collection of files as one ZIP file".  For these kinds of operations,
we need to allow the users to see what's on the file system.  Our
plan is to use the most informative "fancy" index page navigation
that Apache will support, augmented perhaps with some related
file system navigation/browse tools.  In any case, we need to be
able to present unfiltered directory listings.

Thus, in the naming guidelines (approved but not yet announced)
we express this in the words: "TC members must not create filenames that
compete with any reserved filenames used by the system/server or by OASIS
staff for administrative purposes... File names reserved for (future)
administrative use include any files significant to the Apache server
(e.g., .htaccess; *.cgi; *.conf or matching any Apache config files;
mime.types) and files used by Staff for uniform browsing/navigation (e.g.,
index.html, index.htm, etc). A complete list must be provided..."  See:
http://docs.oasis-open.org/specGuidelines/namingGuidelines/resourceNaming.html#nameConstruction

>
> *[c]*
> If suggestion in [b] is not preferred, I would personally want to see a
> "raw directory" listing. (similar to
> http://docs.oasis-open.org/wss/2004/01/ )  in 5 directories for XSD:
> http://docs.oasis-open.org/wsbpel/2.0/process/abstract
> http://docs.oasis-open.org/wsbpel/2.0/process/executable
> http://docs.oasis-open.org/wsbpel/2.0/plnktype
> http://docs.oasis-open.org/wsbpel/2.0/serviceref
> http://docs.oasis-open.org/wsbpel/2.0/varprop

As described earlier, a design goal for the OASIS Open Library is to
always provide transparent ('raw') directory listings: we want users to
be able to see everything.  So yes, the "raw directory" listing is
very acceptable as part of the solution.

>
> We will have only one  XHTML+RDDL as the index.html at the top level
> directory:
> http://docs.oasis-open.org/wsbpel/2.0

It sounds like you want to document the five (5) NS URIs in one
(RDDL) namespace document -- right?  In that case, all five
NS URIs, when dereferenced, will resolve to [the resource
represented by] that single XHTML+RDDL file.

Based upon what I've explained so far, you can predict my answer
to the proposal that "index.html" [ /wsbpel/2.0/index.html ]
be used as the filename for the RDDL: that would be OK, but we
would want to override the default Apache behavior to ensure that
we display the directory listing when a request is made for
either of these resources:

a) http://docs.oasis-open.org/wsbpel/2.0
b) http://docs.oasis-open.org/wsbpel/2.0/

Viz., we would not (want to) display the contents of the
file .../wsbpel/2.0/index.html when a user (agent) makes
an HTTP request for "a)" or "b)" immediately above

>
>
> What we want to achieve in [b]/[c] is:
> given a NS URI (e.g.
> http://docs.oasis-open.org/wsbpel/2.0/process/executable ),
> people can locate its XSD very quickly from http://docs.oasis-open.org
> web site.

That's a very reasonable goal, IMO.

Some designs actually resolve directly to the schema file when the
NS URI is dereferenced.  I don't want to explain here why I think
that's a bad idea.

I think you can design the RDDL document to provide a highly visible
mapping from NS URI to the schema (location) URI.  For example,
you could create an HTML table at the very top of the RDDL document
which displays.  Table header:

(Suggested) prefix |  Namespace URI | Schema Location URI

Visually, the relatiohships would be very clear, and the user
can click on any of the (hyperlinked) Schema Location URIs

** Unfortunately, there's little consensus as of yet about the
structure of RDDL documents in support of machine-to-machine use.

>
> If we select the schema location suggested by your first email this
> morning, e.g.,
> http://docs.oasis-open.org/wsbpel/2.0/schemas/wsbpel_abstract_common_base.xsd
> http://docs.oasis-open.org/wsbpel/2.0/schemas/wsbpel_executable.xsd
> http://docs.oasis-open.org/wsbpel/2.0/schemas/wsbpel_plnktype.xsd
> http://docs.oasis-open.org/wsbpel/2.0/schemas/wsbpel_serviceref.xsd
> http://docs.oasis-open.org/wsbpel/2.0/schemas/wsbpel_varprop.xsd
>
> Then, it will be actually harder for people to locate the file.

I can see why you'd say that. So I believe the RDDL is the best
solution to the problem of making it easy to locate a schema file
if they the NS URI: just dereference the NS URI, and see the
(hyperlinked) schema URI at the top of the RDDL document.

>
> And, if there is a need for an errata for XSD, we can upload the errata
> version of XSD to the same directory. That will mirror similar efforts
> for "http://schemas.xmlsoap.org/wsdl/";

It appears that the downside of the 'xmlsoap.org' design is that we
cannot detect what resources are in the '/wsdl/' directory (assuming
that there is a /wsdl/ direcory).  We want to maximize the visibility
of all resources by exposing the file system.

>
> Please let me know whether [b] or [c] is more feasible for you guys.

I'll discuss the details with Mary McRae.  Meantime, perhaps you can
reflect on the notion that creative use of your RDDL document is
indeed the more natural, effortless, and predictable way of
helping a user get from the NS URI to the Schema location URI.



>
>
> Thanks!
>
>
> Regards,
> Alex Yiu
>
>
>
>
>
> Robin Cover wrote:
>
> >Thanks, Alex.
> >
> >Alas, I have not been fast enough in my communications.
> >
> >The example provided from the existing implementation of
> >WS-RX TC NS URIs is not a good example.  It represents the
> >state of affairs as initially requested by the WS-RX TC,
> >but in subsequent conversations with the (relevant)
> >TC members, it was admitted/agreed that the OASIS
> >implementation at the server level
> >
> >a) using special hand-crafted index files
> >b) with META refresh redirects
> >c) which brings the RDDL document URI into the browser adddress
> >   window when the NS URI is dereferenced
> >
> >is neither desirable nor optimal.
> >
> >Hence, my message of earlier today:
> >
> >   Subject: URIs for RDDLs, WSDLs, Schemas, etc
> >   Message-ID: <Pine.LNX.4.58.0608161358580.6632@dev.oasis-open.org>
> >
> >urged your TC to consider a different strategy which does NOT
> >locate the schema files in the proposed directories -- since the
> >NS URI is in effect overloaded.
> >
> >If you want to follow the example used (currently) for the WS-RX
> >TC, that's OK, but please realize:
> >
> >a) we cannot recommend that solution as optimal or desirable
> >b) we intend to fix the implementation in the WS-RX TC as soon as
> >   we get OASIS IT support -- viz., it will then NOT work
> >   in the manner you now observe
> >c) we intend to fix a couple related implementations that use the
> >   (crude, kludge, hack META refresh redirect mechanism)
> >d) the ebxml-bp TC members initially requested an implementation of
> >   the NOT-recommended type, and we are in the midst of a
> >   painful process to correct that situation by reduplicating
> >   files to a new directory where they can be listed using
> >   standard/default Apache indexing
> >
> >So you say:
> >
> >"If the pattern is feasible for WS-RX, it should work for us also."
> >
> >to which I need to reply:  "the WS-RX TC pattern is not a good
> >implementation pattern to follow," even if it's "feasible"
> >in the sense of being nominally functional.
> >
> >I am very proud of the pioneering work done on RDDLs by Marc
> >Goodner, Chris Ferris, Paul Cotton, and others in the WS-RX
> >TC.  Unfortunately, we were unable to provide an optimal
> >implementation at the server level.  We are trying to avoid
> >further problems by asking TCs to consider an alternate
> >pattern for schema location.  The server implementation
> >(I would characterize as a crude hack) is not something
> >the WS-RX members envisioned or requested: it is the
> >temporary solution provided by OASIS staff.
> >
> >In any case, when OASIS IT provides the requested support
> >for Apache redirects, we will continue to deliver a (RDDL)
> >namespace document when the namespace URI is dereferenced.
> >However, the implementation will be a lot cleaner, and will
> >avoid some of the (reported) DNS/HTTP resolution problems
> >associated with the current implementation.  Using
> >the appropriate Apache directives will also allow us to
> >override the default Apache redirect problem described in
> >my note earlier today.
> >
> >I apologize that I was unable to dive into this discussion
> >earlier.
> >
> >Thanks.
> >
> >Robin Cover
> >
> >On Wed, 16 Aug 2006, Alex Yiu wrote:
> >
> >
> >
> >>Hi Robin,
> >>(cc'ing Prasad and wsbpel-spec-editing list)
> >>
> >>
> >>Thanks for your email.
> >>
> >>Robin wrote:
> >>
> >>
> >>
> >>>a) Directory URI: http://docs.oasis-open.org/wsbpel/2.0/process/abstract/
> >>>b) NS URI: http://docs.oasis-open.org/wsbpel/2.0/process/abstract
> >>>
> >>>The current default server behavior is to issue a redirect from "b)" to "a)" when a user (agent) requests the resource at "b)".  This default handling makes it impossible to produce a (raw, Apache-generated) directory listing for the contents of the "abstract" directory because dereferencing the NS URI needs to produce the associated RDDL namespace document. Given our existing limitations, there's no way to get Apache to list the directory contents, because the URI is overloaded.
> >>>
> >>>
> >>>
> >>>
> >>Not being able to produce a (raw, Apache-generated) directory listing is
> >>fine to me. We don't need a raw directory listen, if we got a XHTML+RDDL
> >>document already. That document is a better way to explain the content
> >>of that directory.
> >>
> >>Let me re-iterate my viewpoint so far by lookin into Mary's WS-RX example:
> >>
> >>schema location =
> >>http://docs.oasis-open.org/ws-rx/wsrm/200510/wsrm-1.1-schema-200510.xsd
> >>targetNamespace =
> >>"http://docs.oasis-open.org/ws-rx/wsrm/200510";
> >>
> >>When people try to use a brower (user-agent) to access
> >>"http://docs.oasis-open.org/ws-rx/wsrm/200510"; or
> >>"http://docs.oasis-open.org/ws-rx/wsrm/200510/";
> >>it will be redirected to the landing page with RDDL:
> >>"http://docs.oasis-open.org/ws-rx/wsrm/200510/wsrm-1.1-rddl-cd-02.html";
> >>
> >>The above pattern fits our need also in general.
> >>
> >>If the pattern is feasible for WS-RX, it should work for us also.
> >>
> >>We just need SIX landing-page (XHTML+RDDL) with the following location:
> >>
> >>One for the top level:
> >>http://docs.oasis-open.org/wsbpel/2.0
> >>
> >>Five for 5 XSD:
> >>http://docs.oasis-open.org/wsbpel/2.0/process/abstract
> >>http://docs.oasis-open.org/wsbpel/2.0/process/executable
> >>http://docs.oasis-open.org/wsbpel/2.0/plnktype
> >>http://docs.oasis-open.org/wsbpel/2.0/serviceref
> >>http://docs.oasis-open.org/wsbpel/2.0/varprop
> >>
> >>
> >>What do you guys think?
> >>
> >>
> >>
> >>Thanks!
> >>
> >>
> >>
> >>Regards,
> >>Alex Yiu
> >>
> >>
> >>
> >>
> >>Robin Cover wrote:
> >>
> >>
> >>
> >>>Alex (and others),
> >>>
> >>>Based upon a posting of 14 Aug 2006 [1] and subsequent
> >>>off-list email messages, I understand that the five
> >>>namespace URIs are to be:
> >>>
> >>>http://docs.oasis-open.org/wsbpel/2.0/process/abstract
> >>>http://docs.oasis-open.org/wsbpel/2.0/process/executable
> >>>http://docs.oasis-open.org/wsbpel/2.0/plnktype
> >>>http://docs.oasis-open.org/wsbpel/2.0/serviceref
> >>>http://docs.oasis-open.org/wsbpel/2.0/varprop
> >>>
> >>>I see no problems at all with these namespace URIs.
> >>>
> >>>The posting from 14 Aug 2006 also identifies five
> >>>corresponding schema location URIs, which (adjusted for
> >>>the ws-bpel -->> wsbpel change) would be:
> >>>
> >>>http://docs.oasis-open.org/wsbpel/2.0/process/abstract/wsbpel_abstract_common_base.xsd
> >>>http://docs.oasis-open.org/wsbpel/2.0/process/executable/wsbpel_executable.xsd
> >>>http://docs.oasis-open.org/wsbpel/2.0/plnktype/wsbpel_plnktype.xsd
> >>>http://docs.oasis-open.org/wsbpel/2.0/serviceref/wsbpel_serviceref.xsd
> >>>http://docs.oasis-open.org/wsbpel/2.0/varprop/wsbpel_varprop.xsd
> >>>
> >>>If the TC wants to insist on these URIs, I believe the OASIS
> >>>IT Staff can adjust to that decision, and provide normal
> >>>but minimal server support for the resources represented by
> >>>the five files at the implied file system locations.
> >>>
> >>>However, for consistency in OASIS operations, it would be
> >>>preferable NOT to store the schemas in the file system
> >>>locations implied by the URIs above, but rather, to store them
> >>>in a separate directory. For example, the five schemas
> >>>could be stored in a directory /schemas/, resulting in this
> >>>set of URIs:
> >>>
> >>>http://docs.oasis-open.org/wsbpel/2.0/schemas/wsbpel_abstract_common_base.xsd
> >>>http://docs.oasis-open.org/wsbpel/2.0/schemas/wsbpel_executable.xsd
> >>>http://docs.oasis-open.org/wsbpel/2.0/schemas/wsbpel_plnktype.xsd
> >>>http://docs.oasis-open.org/wsbpel/2.0/schemas/wsbpel_serviceref.xsd
> >>>http://docs.oasis-open.org/wsbpel/2.0/schemas/wsbpel_varprop.xsd
> >>>
> >>>Let me explain why this would be preferable from the OASIS
> >>>point of view.
> >>>
> >>>At the current time, the OASIS servers associated with the Internet
> >>>domains www.oasis-open and docs.oasis-open.org use configurations
> >>>which are interdependent, and are tuned to reflect different needs
> >>>in Kavi and non-Kavi resources. That means the IT programming team
> >>>cannot, at this time, provide the ideal form of support for
> >>>server behavior when an HTTP scheme URI is dereferenced. For example,
> >>>at this time if the following namespace URI is to be supported,
> >>>
> >>>  http://docs.oasis-open.org/wsbpel/2.0/process/abstract
> >>>
> >>>we would create a directory "abstract" beneath the directory
> >>>"process", yielding the following two URIs:
> >>>
> >>>a) Directory URI: http://docs.oasis-open.org/wsbpel/2.0/process/abstract/
> >>>b) NS URI: http://docs.oasis-open.org/wsbpel/2.0/process/abstract
> >>>
> >>>The current default server behavior is to issue a redirect from "b)"
> >>>to "a)" when a user (agent) requests the resource at "b)".  This
> >>>default handling makes it impossible to produce a (raw, Apache-
> >>>generated) directory listing for the contents of the "abstract"
> >>>directory because dereferencing the NS URI needs to produce the
> >>>associated RDDL namespace document. Given our existing limitations,
> >>>there's no way to get Apache to list the directory contents,
> >>>because the URI is overloaded.
> >>>
> >>>I must clarify that under ideal conditions, server configuration
> >>>tools should allow the IT programming team to implement some
> >>>"non-default" server behavior using Apache directives (e.g.,
> >>>mod_rewrite, mod_alias, mod_dir ) which would avoid the
> >>>redirect from "b)" to "a)" and so forth. [2]
> >>>
> >>>For these reasons, and for some broad concerns for usability in
> >>>our OASIS context (desire for transparent access to the web
> >>>server's file system), it's better not to store content (files,
> >>>directories, symlinks, etc) in directories matching these URIs:
> >>>
> >>>http://docs.oasis-open.org/wsbpel/2.0/process/abstract/
> >>>http://docs.oasis-open.org/wsbpel/2.0/process/executable/
> >>>http://docs.oasis-open.org/wsbpel/2.0/plnktype/
> >>>http://docs.oasis-open.org/wsbpel/2.0/serviceref/
> >>>http://docs.oasis-open.org/wsbpel/2.0/varprop/
> >>>
> >>>If the specification includes WSDL files, RDDL files, and
> >>>perhaps other files associated with the prose document(s)
> >>>and XML schemas. it would be better to store those files
> >>>(WSDLs, RDDLs, XML schemas) in one or more separate
> >>>directories other than in the five referenced immediately
> >>>above.
> >>>
> >>>We can arrange a phone call to discuss details further, if
> >>>that might prove useful.  I would also like to see the complete
> >>>listing of files associated with version 2.0 of the Web
> >>>Services Business Process Execution Language spec.
> >>>
> >>>Robin Cover
> >>>
> >>>PS  You may forward this message to anyone on the design/editorial
> >>>team.
> >>>
> >>>[1] http://lists.oasis-open.org/archives/wsbpel/200608/msg00051.html
> >>>   Subject: Issue - 289 - Proposal to vote
> >>>   * From: Alex Yiu <alex.yiu@oracle.com>
> >>>   * To: wsbpeltc <wsbpel@lists.oasis-open.org>
> >>>   * Date: Mon, 14 Aug 2006 13:25:18 -0700
> >>>
> >>>[2] Apache modules
> >>>
> >>>http://httpd.apache.org/docs/2.0/mod/mod_rewrite.html
> >>>http://httpd.apache.org/docs/2.0/mod/mod_alias.html
> >>>http://httpd.apache.org/docs/2.0/mod/mod_dir.html
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
>
>