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



I got some comments from Chris Ferris (see attached) and spoke to him for some time regarding this proposal.
While Chris is excited by this proposal, he is not on this list so he is not directly responding.

I would offer following thoughts (note some are about face on previous email from me) based on a distillation of that
conversation.

-We should not prescribe any baseURL. Not even "urlInterface" suffix. The registry implementor is free to choose
whatever URL they provide to their URL interface to their ebXML registry.

-The BP should only be in terms of  parameter/values for the HTTP post method. This means removing getRegistryObject
and getRepositoryItem. Replace them with action="getRegistryObject" or action="getReopositoryItem".

-We should suggest that vendors are free to provide value-added features above and beyond this BP specially in the
area of client specified transformation on the content. However, the BP will not describe such behavior.

What do you folks think?


--
Regards,
Farrukh


Farrukh Najmi wrote:

> 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>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.oasis-open.org/ob/adm.pl>


Attachment: chrisOnMattsBP.doc
Description: MS-Word document



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


Powered by eList eXpress LLC