Next in thread →
Next in month →
RE: WS BPEL URIs for RDDLs, WSDLs, Schemas, etc
Hi Diane,
The only outstanding issue is the use of the
filename "index.html". This name is reserved by OASIS. Instead, the RDDL file
should be named something like "wsbpel-v20-rddl.html" -- it should at least
contain the string 'rddl' and end in '.html'; other than that I think we're
ready to go!
Regards,
Mary
From: Diane Jordan [mailto:]
Sent: Wednesday, August 23, 2006 11:04 PM
To: Robin
Cover; ;
Cc:
Subject: WS BPEL URIs for
RDDLs, WSDLs, Schemas, etc
Hi,
Today the TC approved a new committee draft and the
start of public review. Alex asked that I follow up with you to confirm
that the approach he described below is ok.
Please let us know.
Regards, Diane
IBM
Emerging Internet Software Standards
(919)254-7221
or 8-444-7221, Mobile: 919-624-5123, Fax 845-491-5709
----- Forwarded by Diane
Jordan/Raleigh/IBM on 08/23/2006 11:02 PM -----
Alex Yiu
<>
08/16/2006 09:46 PM
To
Robin Cover
<>
cc
"Marin, Mike"
<>, Thomas Schulze
<>, Diane Jordan/Raleigh/IBM@IBMUS,
Mary McRae <>, bpel spec
<>, Prasad Yendluri
<>, Alex Yiu
<>
Subject
Re: [wsbpel-spec-edit] Re: URIs
for RDDLs, WSDLs, Schemas, etc
Hi Robin,
Thanks for the quick reply.
If I understand
your email correctly, a file arrangement based option [c] listed in my
previous email should be OK to OASIS convention. Let me re-iterate the details
of file arrangement again here:
For the following 5 URLs
(with or without the trailing '/'), transparent ('raw')
directory listings will be shown:
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
There will be 5 XSDs uploaded to the above directory locations
as well.
Similarly, the following URL (with or without the
trailing '/'), transparent ('raw') directory listings will be
shown:
http://docs.oasis-open.org/wsbpel/2.0
In the above "/wsbpel/2.0" directory, we will have the
following files:
a PDF file for the spec text
a HTML file for the spec text
an index.html (which is an XHTML+RDDL document) to document
all resources provided by this spec (e.g. PDF + HTML + 5 XSDs). And, we
document the 5 XSD resources, we may use the following pattern:
(Suggested) prefix | Namespace URI |
Schema Location URI
I hope I document our
current intent of directory usage right. If the above usage is acceptable to
OASIS convention, please confirm.
And, I don't have a strong
opinion to add additional XHTML+RDDL documents in 5 XSD directories. One way
or the other is OK to
me.
Thanks!
Regards,
Alex
Yiu
Robin Cover wrote:
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: <>
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 <>
* To: wsbpeltc <>
* 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
Next in thread →
Next in month →