[INFOD-WG] Output from getmetadata is not defined. - action 233
Dieter Gawlick
dieter.gawlick at oracle.com
Wed Aug 22 18:01:57 CDT 2007
Steve,
here is a possible SQL analogy:
The registry is a table containing all documents of interest to INFOD.
The collection function allows us to define various /views/; e.g., the
view (or folder) of all documents conforming to the structure of the
subscriber entry - fn:collection ('$$infodSubscribers'). By applying the
selection (the where clause) we get exactly the subset of documents from
the sub-folder that we are looking for.
The return will deliver a part of all the documents that satisfy the
where clause; which part is returned is specified in the return clause
(the equivalent of the SELECT list).
Dieter
Fisher, SM (Steve) wrote:
> Dieter,
>
> I think that we only describe parts of the document - e.g the publisher
> entry, subscriber entry etc.
>
> Are you saying that because we have functions that will return all
> publishers all subscribers etc that this allows us to write any query we
> like making use of these collections - treating them as similar to views
> on the database i.e. we don't have to actually extract all the data?
>
> Steve
>
>
>> -----Original Message-----
>> From: Dieter Gawlick [mailto:dieter.gawlick at oracle.com]
>> Sent: 22 August 2007 23:29
>> To: Fisher, SM (Steve)
>> Cc: infod-wg at ggf.org
>> Subject: Re: [INFOD-WG] Output from getmetadata is not
>> defined. - action 233
>>
>> Steve,
>>
>> The specific structure of the output depends on the documents
>> structure and the return clause. The structure of documents
>> defined by INFOD is formalized in Appendix I, the structure
>> of properties and data are defined by the user. So, we are
>> all set - at least as far as I understand it.
>>
>> As for the collection function. There is nothing INFOD
>> specific; we just use the generally defined collection
>> function and put into the quotes what is meaningful in the
>> context of the INFOD registry.
>>
>> Lets discuss this more at the conference call.
>>
>> Dieter
>>
>> Fisher, SM (Steve) wrote:
>>
>>
>>
>>
>>
>> -----Original Message-----
>> From: Dieter Gawlick [mailto:dieter.gawlick at oracle.com]
>> Sent: 22 August 2007 19:12
>> To: Fisher, SM (Steve)
>> Cc: infod-wg at ggf.org
>> Subject: Re: [INFOD-WG] Output from getmetadata is not
>> defined. - action 233
>>
>> Steve,
>>
>> the output is precisely specified in the
>> following documents:
>>
>> http://www.w3.org/TR/xpath-datamodel/
>>
>> and
>>
>> http://www.w3.org/TR/xslt-xquery-serialization/
>>
>> I think we have to add a foot note in the
>> specifications; we
>> - the INFOD group - not try to specify this.
>>
>>
>>
>> I agree completely that we are not to specify in
>> general terms what the
>> results of an XQuery looks like. However the specific
>> output depends
>> upon the document which is being queried and we have
>> not specified what
>> that document looks like. We have gone a little way to
>> addressing this
>> with the various functions to get all publishers etc.
>> however this is
>> very crude as we don't want to get all the data out of
>> the registry to
>> make sense of it. I presume that when we get all
>> publishers that each
>> publisher is defined as in the Publisher Entry in section 5.1
>>
>> We say on lines 1630-1631 that we can support
>> Xpath/Xquery expressions -
>> but how can we unless we say what the document being
>> queried looks
>> like???
>>
>> An alterntive route would be to supply a huge number of
>> functions - but
>> this seems rather unwise.
>>
>> Steve
>>
>>
>>
>> Dieter
>>
>> Fisher, SM (Steve) wrote:
>>
>> Hi,
>>
>> This has been rolling on for a while
>> and I would like
>> to get agreement
>> on what we should do.
>>
>> The spec says the output of getMetaData is a
>> GetMetaDataQueryResponse
>> which is:
>>
>> <infod:GetMetaDataQueryResponse>
>> <infod:MetaDataQueryResult>
>> {xsd:anyType}
>> <infod:GetMetaDataQueryResult>
>> <infod:MetaDataQueryResponse>
>>
>> I was concerned that this makes
>> interoparability
>> impossible. Ronny
>> replied:
>>
>> "... I don't think we can be more
>> specific than that.
>> We require the
>> "any" to be the XML-"blob" that you are
>> asking about.
>> Everything is in
>> the registry - including data
>> vocabularies. And through
>> the functions
>> that dieter provided ... you can get to
>> every place in
>> the registry. In
>> general you will receive an xml doc
>> within the "any"
>> .... I still think
>> interoperability is not a problem..."
>>
>> I agree that what we are doing is fully
>> consistent with
>> the spec -
>> however I do not see how two
>> implementations can be
>> interoperable unless
>> we can guarantee that even though the
>> return type is
>> the xml blob, if
>> someone defines the same properties and
>> vcaobularies on
>> two different
>> implementations and makes a getMetaData
>> call the xml
>> blob will be
>> identical. We will need to define a
>> test suite to demonsatrate
>> interoperability and I expect we are
>> going to fail
>> badly in this area.
>>
>> Steve
>>
>> --
>> infod-wg mailing list
>> infod-wg at ogf.org
>> http://www.ogf.org/mailman/listinfo/infod-wg
>>
>>
>>
>> --
>>
>>
>> Oracle Email Signature Logo
>> Dieter Gawlick | Architect | 650.506.8706
>> Oracle Server Technologies
>> 500 Oracle Parkway | Redwood Shores, CA 94065
>>
>>
>>
>>
>> --
>>
>>
>> Oracle Email Signature Logo
>> Dieter Gawlick | Architect | 650.506.8706
>> Oracle Server Technologies
>> 500 Oracle Parkway | Redwood Shores, CA 94065
>>
>>
--
Oracle Email Signature Logo
Dieter Gawlick | Architect | 650.506.8706
Oracle Server Technologies
500 Oracle Parkway | Redwood Shores, CA 94065
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/infod-wg/attachments/20070822/9ee8d946/attachment.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: oracle_sig_logo.gif
Type: image/gif
Size: 658 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/infod-wg/attachments/20070822/9ee8d946/attachment.gif
More information about the infod-wg
mailing list