RE: LC 104 and the abstract info model for EPRs

 

> -----Original Message-----
> From: public-ws-addressing-request@w3.org 
> [mailto:public-ws-addressing-request@w3.org] On Behalf Of 
> Jonathan Marsh
> Sent: Friday, Jul 08, 2005 11:19 AM
> To: Nilo Mitra (TX/EUS); tom@coastin.com; Anish Karmarkar
> Cc: public-ws-addressing@w3.org
> Subject: RE: LC 104 and the abstract info model for EPRs
> 
> 
> Very interesting work.  It does appear to be simpler on the surface,
> especially for the EPR properties (though some slight 
> clarifications in
> Section 2 about what the "value" is would be nice - mostly
> s/value/EII/).  This works because we can stop talking about 
> properties
> altogether.
> 
> However, it's not quite so clean in the Message Addressing Properties
> section.  We still talk about properties, but conflate the names of
> these properties with the elements that represent them, which 
> will lead
> to confusion.  I think it's particularly confusing for wsa:RelatesTo.
> If I say "the wsa:RelatesTo property has the value 
> 'mid:***'", does that
> imply that there is no wsa:Relatesto/@RelationshipType value?  Does
> wsa:RelatesTo mean the property or the structure, or is it a 
> structured
> property?  I think you've removed some terminology which is 
> designed to
> differentiate distinct concepts.  So while it may appear simpler, it
> reduces clarity - not a win-win.
> 
> It appears to me that adopting just the EPR part of your 
> proposal would
> satisfy LC101 and LC104.

To be specific, are you saying that collapsing Section 2.1 and Section
2.2 is appropriate, but Section 3.1 and Section 3.2 is not? 

--umit

> 
> -----Original Message-----
> From: public-ws-addressing-request@w3.org
> [mailto:public-ws-addressing-request@w3.org] On Behalf Of Nilo Mitra
> (TX/EUS)
> Sent: Thursday, July 07, 2005 10:35 AM
> To: tom@coastin.com; Anish Karmarkar
> Cc: public-ws-addressing@w3.org
> Subject: RE: LC 104 and the abstract info model for EPRs
> 
> 
> +1
> 
> Nilo 
> 
> > -----Original Message-----
> > From: public-ws-addressing-request@w3.org 
> > [mailto:public-ws-addressing-request@w3.org] On Behalf Of Tom Rutt
> > Sent: Thursday, July 07, 2005 1:10 PM
> > To: Anish Karmarkar
> > Cc: public-ws-addressing@w3.org
> > Subject: Re: LC 104 and the abstract info model for EPRs
> > 
> > 
> > Anish Karmarkar wrote:
> > 
> > > I took an action item to kick off a discussion on LC 104.
> > 
> > I find this edit to be very readable.
> > 
> > I prefer this edit to remove abstract properties to the 
> > original text.  
> > I changes nothing technically.
> > 
> > Tom Rutt
> > Fujitsu
> > 
> > >
> > > Thinking about LC 104 and LC 101, I have the following
> > > questions/comments:
> > >
> > > What is the purpose of section 2.1 [1], the abstract 
> > information model 
> > > for EPRs?
> > >
> > > Currently the spec defines an abstract model and then a 
> mapping to 
> > > Infoset. Infoset itself being abstract and which can be 
> > further mapped 
> > > to XML 1.0 or XOP or a binary serialization (eg, IT/UT's 
> ASN.1 based
> > > serialization) or something else. This is an XML spec, so 
> it seems 
> > > that an Infoset model should be sufficient. I haven't heard of 
> > > requirements/usecases for an abstract model for EPRs (for 
> which an 
> > > infoset is not sufficient). The abstract properties are 
> in any case 
> > > specified in terms of XML schema types. It seems to me that -
> > >
> > > 1) This unnecessarily complicates and lengthens the spec with no 
> > > advantage.
> > > 2) This also results in pesky problems such as those 
> > pointed by LC 104 
> > > and LC 101 -- how does one extend an EPR at the abstract 
> > level? At the 
> > > infoset level it is clear as there are extensibility 
> > > elements/attributes. How are the extensible 
> > attributes/elements in the 
> > > Infoset (eg: attributes of wsa:EndpointReference element) 
> > > reverse-mapped back to the abstract model? Something like
> > > /wsa:EndpointReference/@myext:Ext1 attribute has to be 
> > mapped to the 
> > > abstract model but something like 
> /wsa:EndpointReference/@xml:lang 
> > > does not necessarily have to be mapped. How does one distinguish 
> > > between the two and what does the spec have to say about this and 
> > > about extensibility guidelines and framework.
> > > 3) Following the principle: Things should be made as simple as 
> > > possible, but no simpler -- it seems to make sense to remove the 
> > > abstract model, unless someone can demonstrate a real 
> need for this 
> > > (and Infoset is not sufficient).
> > >
> > > To see what the spec would look like without the abstract 
> > model and to 
> > > figure out how much work/change is needed, I took the 
> > current spec and 
> > > removed the abstract model (for both EPRs and MAPs) 
> > sections, merged 
> > > the still-relevant text from the deleted sections with 
> the infoset 
> > > stuff, changed [...] to /wsa:..., + some misc changes to 
> > accommodate 
> > > the deleted sections (such as removal of text from the 'notation'
> > > section). The changed version is attached. I used HtmlDiff 
> > to create 
> > > diff'ed version (which is also attached). Pl. note that 
> > some text was 
> > > moved from one section to another, but the diff version 
> > just shows a 
> > > delete-and-add.
> > >
> > > Overall, the changes (from an editorial perspective) are 
> > minor. Such a 
> > > change would also require some very minimal changes in the 
> > > SOAP-binding and WSDL-binding specs (to refer to the 
> QNames rather 
> > > than [...] properties).
> > >
> > > Please note that there were some cardinality constraints 
> > ('?' and '*') 
> > > missing in the infoset mapping for MAP, which I added -- this had 
> > > nothing to do with the removal of the abstract model.
> > >
> > > Comments?
> > >
> > > -Anish
> > > --
> > >
> > > PS: for those who are worried about 2nd LC, AFAIK, removing 
> > a feature 
> > > does *not* trigger another LC (but adding a feature may).
> > >
> > >
> > > [1]
> > > 
> > 
> http://dev.w3.org/cvsweb/~checkout~/2004/ws/addressing/ws-addr-core.ht
> > > ml?content-type=text/html;%20charset=utf-8#eprinfomodel
> > >
> > >
> > > 
> > 
> ----------------------------------------------------------------------
> > > --
> > 
> > ----------------------------------------------------
> > Tom Rutt	email: tom@coastin.com; trutt@us.fujitsu.com
> > Tel: +1 732 801 5744          Fax: +1 732 774 5133
> > 
> > 
> > 
> > 
> 
> 
>

Received on Friday, 8 July 2005 21:29:19 UTC