FW: [wsbpel-spec-edit] RE: WS BPEL URIs for RDDLs, WSDLs, Schemas ,etc

Forgot to cc the spec list…

 

From: John Evdemon 

Sent: Monday, August 28, 2006 11:44 AM

To: 'Prasad Yendluri'; Diane Jordan

Subject: RE: [wsbpel-spec-edit] RE: WS BPEL URIs for RDDLs, WSDLs,
Schemas , etc

 

I can do this if you like – do we already have a RDDL file
or shall I pull one together?

 

BTW - No news from OASIS on the XHTML file to me means they are
OK with it.

 

Someone pls send me the RDDL file or let me know if I need to
create it.

 

Thanks!

 

John

 

From: Prasad Yendluri
[mailto:] 

Sent: Monday, August 28, 2006 11:31 AM

To: Diane Jordan; John Evdemon

Subject: FW: [wsbpel-spec-edit] RE: WS BPEL URIs for RDDLs, WSDLs,
Schemas , etc

Importance: High

 

John, Diane,

 

Given the issue with XHTML conformance issue with OASIS, I would
request that John handle this one also.

 

Thanks.

 

Prasad

 

From: Alex Yiu [mailto:] 

Sent: Friday, August 25, 2006 5:25 PM

To: 

Cc: 'Diane Jordan'; 'Robin Cover';
; Alex Yiu

Subject: Re: [wsbpel-spec-edit] RE: WS BPEL URIs for RDDLs, WSDLs,
Schemas, etc

 

Hi all,

I have no preferences in terms of file name. Something like
"wsbpel-v20-rddl.html" is good enough for me.

Thanks!

Regards,

Alex Yiu

Mary McRae wrote: 

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