[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [regrep] [Fwd: [JIRA] Updated: (REGREPTC-118) Need QueryResponseto allow returning non-RegistryObjectList response such as a SPARQL response.]
David RR Webber (XML) wrote: > Farrukh, > > There's a lot of things they suggest that have all kinds of ugly > impacts for developers. > > I mean why not just have <xsd:schema><xsd:any/></xsd:schema> > > What's not to like?!? ; -) > > Since we're developing a standard - that should encourage > interoperability - I'd suggest that use of xsd:any is at best an ugly > bandaid. It only makes sense for elements such as <PayLoadGoesHere>, > whereas anything else should be giving strong guidance to implementers > concerning what to expect. There is no sacrificing interop with use of xs:any. The OWL profile for example defines that xs:any to be a sparqlx:sparql element very interoperably. > > I'm back to suggesting an extensible xsd:token definition with a > default base type - that way people can add their own restriction and > enumerations as needed - but minimum coding then expects a token - and > basic validation will restrict that - much cleaner - handles empty > values already, etc, etc - reduces coding overhead, maintenance, et al. > > Thanks, DW > > -------- Original Message -------- > Subject: Re: [regrep] [Fwd: [JIRA] Updated: (REGREPTC-118) Need > QueryResponse to allow returning non-RegistryObjectList response > such as > a SPARQL response.] > From: Farrukh Najmi <farrukh@wellfleetsoftware.com> > Date: Thu, October 22, 2009 3:45 pm > To: "David RR Webber (XML)" <david@drrw.info> > Cc: ebXML Regrep <regrep@lists.oasis-open.org> > > > Yes we could create a SPARQLQueryResponse as an extension of > QueryResponse. However, it seems to me that having this sort of > core extensibility is better. If we do the proposed way then the > OWL profile and other profiles need not defione any extension > schema at all. > > Note that XML Schema best practices suggest liberally sprinkling > <xsd:any> all over your schema. I tend to use them like Cod Liver > oil (only when needed): > > <http://www.xfront.com/ExtensibleContentModels.html#BestPractice> > > The proposed solution is a one size fits all solution that will > handle not just SPARQL but many other query response formats. > > David RR Webber (XML) wrote: >> Farrukh, >> >> Do we really want xsd:any in response type? >> >> I prefer something more explicit - such as an attribute token - >> and then at least you know what to expect back. >> >> Is the issue that we just want to include various OWL component >> types? If so - I would have thought we can create an OWL-types >> extension and have that - rather than leaving it completely open >> ended for implementers to have to cope with. >> >> Thanks, DW >> >> -------- Original Message -------- >> Subject: [regrep] [Fwd: [JIRA] Updated: (REGREPTC-118) Need >> QueryResponse to allow returning non-RegistryObjectList >> response such as >> a SPARQL response.] >> From: Farrukh Najmi <farrukh@wellfleetsoftware.com> >> Date: Thu, October 22, 2009 12:49 pm >> To: ebXML Regrep <regrep@lists.oasis-open.org> >> >> Dear colleagues, >> >> Please comment on this new issue and proposed solution. >> >> Note that this allows the following spec content to be >> written for OWL profile 2.0: >> >> >> QueryResponse Requirements >> >> A server MUST process a SPARQL query and return its response >> within a QueryResponse. The following additional requirements >> are defined for a server to return a QueryResponse for a >> SPARQL query: >> >> * >> >> A server MUST process the SPARQL query according to >> [SPARQL] within the context of the OWL content >> published within its repository. Specifically a server >> SHOULD NOT need to query its Registry metadata to >> process the SPARQL query >> >> * >> >> A server MUST return the SPARQL response as a >> sparqlx:sparql element in the SPARQL Query Results XML >> Format as specified by [SPARQLX] >> >> * >> >> The sparqlx:sparql MUST be the child element of the >> query:QueryResponse element >> This part of the spec relies on core query.xsd schema >> to be fixed per issue 118 >> <http://wxforge.wx.ll.mit.edu:8080/jira/browse/REGREPTC-118>. >> We assume there will be an xs:any added to >> rs:RegistryResponseType which is extended by >> query:QueryResponse. >> >> * >> >> The QueryResponse element SHOULD NOT have a >> query:RegistryObjectsList child element >> >> The following example shows SPARQL response within a >> QueryResponse: >> >> <query:QueryResponse ...> >> ... >> *<sparqlx:sparql> >> **</sparqlx:sparql> >> *<query:QueryResponse> >> >> >> >> Thanks. >> >> >> -- >> Regards, >> Farrukh >> >> Web: http://www.wellfleetsoftware.com >> >> >> >> ------------------------------------------------------------------------ >> --------------------------------------------------------------------- >> To unsubscribe from this mail list, you must leave the OASIS >> TC that >> generates this mail. Follow this link to all your TCs in >> OASIS at: >> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php >> >> > > > -- > Regards, > Farrukh > > Web: http://www.wellfleetsoftware.com > > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC > that generates this mail. Follow this link to all your TCs in > OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php -- Regards, Farrukh Web: http://www.wellfleetsoftware.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]