[INFOD-WG] Output from getmetadata is not defined. - action 233

[Dieter Gawlick]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/infod-wg/attachments/20070822/e73ebbbc/attachment.htm 
-------------- 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/e73ebbbc/attachment.gif