RE: [regrep] [Fwd: [JIRA] Updated: (REGREPTC-118) Need QueryResponse toa

-------- 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

regrep message