OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [regrep] URL Interface to OASIS ebXML Registry Proposal


Matt,

The baseURL is still completely arbitrary under the suggestion from Zach. The only difference is that the path
elements between the base and the action has an extra element to identify that this is an ebXML registry's
urlInterface and not a urlInterface to something unknown.

I think it is a good idea, but lets hear some other opinions.

BTW in yesterday's meeting, Kathryn suggested that we find out the OASIS rules surrounding best practice (BP)
documents. She took the AI to look into it. I volunteered to be a champion for the concept of best practice
documents as a way to reflect developer/vendor consensus on best ways of doing things that are not currently
defined by the specs.

Thanks again for proposing our first BP paper. I hope that the TC will define a process of approving BP papers and
placing them on our TCF web site.

--
Regards,
Farrukh


Matthew MacKenzie wrote:

> Farrukh,
>
> I'll make the UUID format change ASAP.  I am not opposed to making a
> more rigid definition of the URL format, is that the consensus?
>
> -Matt
> On Friday, May 3, 2002, at 05:58 AM, Farrukh Najmi wrote:
>
> > Zach,
> >
> > The proposal suggests an arbitrary base URL (e.g.
> > http://www.acme.com/foo)
> > followed by a required "urlInterface" path element followed by the
> > action and
> > parameters.
> >
> > <baseURL>/urlInterface/<action>[?[<param>=<value>]*]
> >
> > I think what you are suggesting is that there should be a standard path
> > element that identifies this as an ebXMl Registry. Your suggestion would
> > modify above pseudo-BNF to be like:
> >
> > <baseURL>/ebxmlRegistry/urlInterface/<action>[?[<param>=<value>]*]
> >
> > If that is your intent, I definitely second that suggestion. I think it
> > adds a
> > little more clarity to the URL. So a sample might be:
> >
> > http://www.acme.com/ebxmlRegistry/urlInterface/getRegistryObject?id=http:
> > //registry.example.com/ebreg/urlInterface/getRegistryObject?id=urn:uuid:6E383C7E-538D-11D6-8DC0-00039366D620
> >
> > BTW this also reminds me that line 96 in v0.4 should include urn:uuid
> > in the
> > id value.
> >
> > I also ask Kathryn, if it is appropriate to move this discussion to the
> > cooperating-registries mailing list soon.
> >
> > Zachary Alexander wrote:
> >
> >> Matt,
> >>
> >> Would you feel more comfortable with a "Suggested URL Access Point."  I
> >> think that it would help adoption and utilization if you could assume
> >> that
> >> www.example.com/registry will point to a ebxml registry.
> >>
> >> zack
> >>>> 2) Line 60 URL Access Point for the URL-based interface:
> >>>>
> >>>>      a) Will the spec define a default URL Access Point?
> >>
> >>> No.  This would be implementation specific.  The best practice only
> >>> seeks to define the part of the URL which defines the actions.
> >>> Furthermore, I am not sure how we could define a default access point,
> >>> as that will change from host to host and implementation to
> >>> implementation.  I assume that the access point for a registry will be
> >>> advertised on the registry's proprietary web/other UI, or in product
> >>> documentation.
> >>
> >> -----Original Message-----
> >> From: mattmackenzie [mailto:matt@xmlglobal.com]
> >> Sent: Friday, May 03, 2002 12:10 AM
> >> To: zack2@cris.com
> >> Cc: OASIS Reg-Rep
> >> Subject: Re: [regrep] URL Interface to OASIS ebXML Registry Proposal
> >>
> >> Zack,
> >>
> >> My answers are inline:
> >>
> >> On Thursday, May 2, 2002, at 08:23 PM, Zachary Alexander wrote:
> >>
> >>> Matthew,
> >>>
> >>> 1) What is returned from the request?  Is it straight XML?
> >>>
> >>
> >> If it's a registry object, I would assume so.  If it's a repository
> >> item, that depends on what the content actually is.   As this best
> >> practice is targeting only HTTP, I would expect that implementors would
> >> make good use of the HTTP Content-Type header.
> >>
> >>> 2) Line 60 URL Access Point for the URL-based interface:
> >>>
> >>>       a) Will the spec define a default URL Access Point?
> >>
> >> No.  This would be implementation specific.  The best practice only
> >> seeks to define the part of the URL which defines the actions.
> >> Furthermore, I am not sure how we could define a default access point,
> >> as that will change from host to host and implementation to
> >> implementation.  I assume that the access point for a registry will be
> >> advertised on the registry's proprietary web/other UI, or in product
> >> documentation.
> >>
> >>>
> >>>       b) Will the access point support an index page?
> >>>
> >>
> >> This best practice document defines a lowest-common-denominator
> >> interface.  If an implementor would like to extend it to contain more
> >> actions and default actions, they are more than welcome to.  The
> >> purpose
> >> of this is to provide a uniform way of linking to content managed by an
> >> ebXML registry.
> >>
> >> Regards,
> >>
> >> Matt
> >>
> >> ----------------------------------------------------------------
> >> To subscribe or unsubscribe from this elist use the subscription
> >> manager: <http://lists.oasis-open.org/ob/adm.pl>
> >
> > --
> > Regards,
> > Farrukh
> >
> >
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>






[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC