Subject: Re: [regrep] [Fwd: [regrep-comment] Public Comment]
I fully support this - in fact, there was a discussion about this very concept today at the XML.gov Users Group (David Webber was there as well). The question came up of how one can harmonize submitted data elements with existing elements in a registry, and I commented that one should be able to use (for example) SQL Query to find elements whose names are %LIKE% the submitted element (and potentially other criteria such as classification, to ensure that context comes into play during such an operation). So if one were able to supply (for example) an element name as a parameter to a SQL Query (that is perhaps a stored procedure), that would enable a "semi-automated harmonization function" to be possible for the registry. I say "semi" because there should - at some point - be a human in the loop to inspect the results and make determinations on accuracy of the results. Oh, yeah, and our semantic-aware registry registry would certainly make this much easier... Joe Farrukh Najmi wrote: > > Team, > > Dont know if everyone automatically gets external comments so I am > forwarding it. > > Here is my initial thinking. > > The use case Richard mentions makes sense. I have often heard this need. > The functionality > closely resembles database triggers in relational databases. > > Looking at our V3 schema I realize that we already store queries in the > registry for supporting the > Selector Query for event notification. Providing support for this > feature requires only the ability > to submit an AdhocQuery that identifies a stored query and its > parameters. This could easily be done > using canonical Slots on a AdhocQueryRequest (another already existing > feature). > > For example one special slot could identify the id of the stored query, > while additional Slots could provide > parameters as name, value pairs. The names would match parameter names > in the parameterized query. No > actual query string would be specified as it is already in the registry. > > The rest of the query processing would be identical to current queries. > > This seems like a high bang-for-buck feature to add to version 3.0. If > there is support for this feature for 3.0 then > I can volunteer to specify it in a separate email for the teams review. > > What do people think. Kathryn can we please add this to our next con > call agenda. Thanks. > > -------- Original Message -------- > Subject: [regrep-comment] Public Comment > Date: Wed, 18 Feb 2004 16:30:46 +0000 > From: email@example.com > Reply-To: firstname.lastname@example.org > To: email@example.com > > Comment from: firstname.lastname@example.org > > Dear ebXML Registry TC members, > > We in Government of Canada have been using ebXML Registry to support the work of two Government Online initiatives, and to provide the facilities to support many future initiatives. We are pleased with the many good features in version 2.5 and anxiously await its completion as version 3.0. > > One feature we think would be very valuable in version 3.0 is a parameterized query feature. We envision such a feature to allow storing a query in the registry such that it has place holders > > defined for its parameters. A user could invoke a parameterized query simply by identifying the query and supplying its parameters. > > We feel that parameterized query feature is important because it allows a Registry Admin to store commonly used queries in the registry as a shared resource for the entire user community. It also hides the complexity of queries and only requires users to supply parameter values. > > Please consider adding a parameterized query feature to version 3.0 of ebXML Registry. > > Thank you, > > Richard Lessard > > Programmer/Systems Analyst > > Public Works and Government Services Canada > > 11 Rue Laurier, PdP III, 4A1. Hull, Quebec K1A 0S5 > > Phone : (819) 956-0550 > > email@example.com > > To unsubscribe from this list, send a post to firstname.lastname@example.org, or visit http://www.oasis-open.org/mlmanage/. > > -- > Regards, > Farrukh > > To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/regrep/members/leave_workgroup.php.