RE: LC 104 and the abstract info model for EPRs

Yes, though I'd prefer to close the issue without action, I'd be willing
to collapse 2.1 into 2.2.

> -----Original Message-----
> From: Yalcinalp, Umit [mailto:umit.yalcinalp@sap.com]
> Sent: Friday, July 08, 2005 2:29 PM
> To: Jonathan Marsh; 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
> 
> 
> 
> > -----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 Monday, 11 July 2005 19:08:38 UTC