[INFOD-WG] Output from getmetadata is not defined. - action 233
Fisher, SM (Steve)
S.M.Fisher at rl.ac.uk
Thu Aug 23 02:50:35 CDT 2007
Dieter,
OK this is beginning to make me feel much happier. We only need to
change a very few words in the spec to clarify.
We say on lines 1630 to 1631: "In addition to supporting user defined
Xpath/XQuery expressions, INFOD reserves the following paths and
mandates their implementation."
However any user defined expressions must be in terms of these functions
as they provide the only standard access to the metadata.
Steve
> -----Original Message-----
> From: Dieter Gawlick [mailto:dieter.gawlick at oracle.com]
> Sent: 23 August 2007 00:02
> To: Fisher, SM (Steve)
> Cc: infod-wg at ggf.org
> Subject: Re: [INFOD-WG] Output from getmetadata is not
> defined. - action 233
>
> 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
>
More information about the infod-wg
mailing list