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 9031 - MEX: Dialect is problematic
Summary: MEX: Dialect is problematic
Status: CLOSED REMIND
Alias: None
Product: WS-Resource Access
Classification: Unclassified
Component: MetadataExchange (show other bugs)
Version: LC
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Doug Davis
QA Contact: notifications mailing list for WS Resource Access
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-02-16 20:08 UTC by Doug Davis
Modified: 2010-07-27 20:27 UTC (History)
0 users

See Also:


Attachments

Description Doug Davis 2010-02-16 20:08:45 UTC
The Dialect isn't composible, extensible and is problematic.

Right now each piece of metadata is required to create a new Dialect URI
so that the Dialect value can uniquely identify that piece of metadata.
This is problematic for a couple of reasons:

1 - it forces each new metadata creator to take MEX into account and create
a unique URI for each type of metadata.  This obviously doesn't work for
existing metadata types, nor is it appropriate to force people to create
a special URI just so that MEX can work.

2 - given that metadata creators may not do this, it will then require some
3rd party to be the keeper of mex Dialect URIs.  Who will
take on this role?  How will we ever have interop w/o this overlord?  :-)

This really is very similar to the problem we saw with @mode in ws-eventing.

Proposal:
Change Dialect to be a QName rather than a URI and have it be the root QName
of the metadata.

This obviously will uniquely identify the metadata type in question and it 
doesn't require the creation of a unique URI to go along with it 
(thus no overlord is needed).

This will also remove the need for MEX to define 
Dialect IRI/MetadataFormat table in section 5 - so it can be removed.
Comment 1 Robert Freund 2010-03-30 19:50:24 UTC
resolved as proposed