This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 6604 - MEX: Define a way to ask for more than one MEX dialect
Summary: MEX: Define a way to ask for more than one MEX dialect
Status: CLOSED REMIND
Alias: None
Product: WS-Resource Access
Classification: Unclassified
Component: MetadataExchange (show other bugs)
Version: FPWD
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Doug Davis
QA Contact: notifications mailing list for WS Resource Access
URL:
Whiteboard:
Keywords: hasProposal
Depends on:
Blocks:
 
Reported: 2009-02-21 02:03 UTC by Doug Davis
Modified: 2009-04-21 21:29 UTC (History)
1 user (show)

See Also:


Attachments

Description Doug Davis 2009-02-21 02:03:44 UTC
Add a feature to MEX to allow a client to specify a list of dialects (and identifiers).
Need to think about whether to allow the the "format" (or whatever we called it) to be on a per dialect basis or not.  Thoughts on this would be appreciated.
Comment 1 Doug Davis 2009-02-21 14:53:38 UTC
Current form:
  <mex:GetMetadata ... >
    (<mex:Dialect>xs:anyURI</mex:Dialect>
       (<mex:Identifier>xs:anyURI</mex:Identifier>)?
    )?
    <mex:Content> xs:anyURI </mex:Content> *
  </mex:GetMetadata>

Proposal:
 <mex:GetMetadata ... >
   <mex:Dialect uri="xs:anyURI" 
                identifier="xs:anyURI"? 
                Content="xs:anyURI"? .../> *
   ...
 </mex:GetMetadata>

This gives you the flexibility of choosing different formats on a per Dialect basis.  What's nice about this is that since we've defined the "all" Content URI, you could ask for all forms of a certain metadata with a single element.  However, if you want just 2 of the forms (e.g. URI and EPR) then you'll need to use 2 elements.  Not a huge issue and I'm not sure one that will happen too often.  It seems that if you want a reference to the data you'll probably plan on only using one way to retrieve it - not both.

We could make the Content attribute a list of URIs, but that seems overly complicated when adding a new Dialect element gives you the same end result with only a few more bytes on the wire.
Comment 2 Robert Freund 2009-03-10 20:06:39 UTC
proposal in comment #1 accepted
Comment 3 Doug Davis 2009-03-18 02:48:55 UTC
Done