[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.]
Hi David, We already use xs:any in our schema. This is not a new pattern. Implementations should ignore any elements that the core spec or profiles they implement do not specify. I am not quite seeing how this is different than existing use of xs:any where we need to allow profiles to define extend the content models. The reason for using xs:any rather than a new OWL Profile specific sub-type is to make extension easier for profiles without needing to define new schemas. David RR Webber (XML) wrote: > Farrukh, > > That's fine for OWL - but ANYONE can start putting any content in here > - not just OWL. > > Then that becomes a problem. Including insertion attacks BTW... > > 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 4:31 pm > To: "David RR Webber (XML)" <david@drrw.info> > Cc: ebXML Regrep <regrep@lists.oasis-open.org> > > 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 > > > --------------------------------------------------------------------- > 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]