Re: LC 104 and the abstract info model for EPRs

Comments inlined.

-Anish
--

Jonathan Marsh wrote:
>>-----Original Message-----
>>From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com]
>>Sent: Monday, July 11, 2005 10:23 AM
>>To: Jonathan Marsh
>>Cc: Nilo Mitra (TX/EUS); tom@coastin.com; public-ws-addressing@w3.org
>>Subject: Re: LC 104 and the abstract info model for EPRs
>>
>>Jonathan Marsh wrote:
>>
>>>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.
>>>
>>
>>Yes, that was one of the intentions for changing the EPR section.
>>
>>Pl. note that, I had assumed that if the WG accepted the direction of
>>the proposal, the editors would change things to make it sound better,
>>make clarifications, etc.
> 
> 
> I had assumed that also, but I think there are other (non-editorial)
> terminological changes that might pop up.
> 
> 
>>I grepped for 'value' in section 2, but did not find it. Did you mean
>>section 2 (or a subsection in it) or some other section?
> 
> 
> Oops, meant Part 2.  I meant occurrences of 'value' such as "The value
> of each message addressing property that is of type IRI MUST be
> serialized as an absolute IRI in the corresponding SOAP header block."
> That would take some reconstructive surgery.
> 

You mean the SOAP binding?
If so, yes there would have to be some changes to that spec, but don't 
think I would call it 'reconstructive surgery'.

> 
>>>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 could not get away from using the term 'properties'. Unlike an EPR,
>>MAPs are a collection of things which don't have a single (container)
>>representation or an "identifier". Since we need a term to refer to
> 
> the
> 
>>collection of things that augment the message it made sense to retain
>>the term MAP.
>>
>>The way I see it is that these are properties which are identified by
>>QNames. For example, the 'wsa:Action' property. I find that simpler
> 
> than
> 
>>saying the [action] property which is mapped to wsa:Action EII.
> 
> 
> Well, we'll have to disagree.  I think talking about an wsa:Action
> property is messier because "wsa:Action property" is too similar to
> "wsa:Action".
> 
> 
>>>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?
>>
>>Isn't that true even when you say:
>>"[relationship] property has a value of 'mid:***'"
>>wsa:RelatesTo is a complex structure, just saying that it has a value
> 
> of
> 
>>'mid:***' makes it ambiguous regardless of what you call it.
> 
> 
> No.  We define the mapping from the XML Infoset to [relationship]
> precisely so I know just what that means.
> 

Hmm. I don't quite see that.

> 
>>>Does
>>>wsa:RelatesTo mean the property or the structure, or is it a
> 
> structured
> 
>>>property?
>>
>>"wsa:RelatesTo" is an EII. "wsa:RelatesTo property" is an MAP which is
> 
> a
> 
>>structured property (similar to [relationship] property as it stands
>>right now).
> 
> 
> The separation of these concepts is not made clearly in your proposal.

Perhaps. I'll take a look again.

> I believe distinguishing these concepts would undo much of the
> "simplification" you desire.  For instance, I don't see you can collapse
> the sections as you've done.
> 
> 
>>>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.
>>>
>>
>>Are you suggesting that the name of the property and the EII has to be
>>different? They are certainly distinct. For example, wsa:Action EII
> 
> may
> 
>>be used, say, as part of the SOAP payload -- in which case, it is just
>>payload and has no bearing on the wsa:Action MAP of that message
> 
> (which
> 
>>will depend on value of the SOAP header wsa:Action). But it does not
>>seem like this requires calling it [action] property as opposed to
>>wsa:Action property. But if calling it [action] makes sense, that
> 
> would
> 
>>be fine too. My goal was to remove the abstract section and say that
>>this is all Infoset.
> 
> 
> I don't get it.  You say it's distinct, but then also say you want to
> remove the abstract section.  Aren't those contradictory statements?
> 

No. There is only one representation -- XML infoset, as opposed to an 
abstract model and an XML infoset rep (and possibly more)

> 
>>I don't particularly care whether it is called "wsa:Action property"
> 
> or
> 
>>"[action] property", it just seems simpler to call it wsa:Action
> 
> property.
> 
> You have done more than just rename.  But even if that's all you want to
> do, I'd rather keep the current names.
> 
> 
>>>It appears to me that adopting just the EPR part of your proposal
> 
> would
> 
>>>satisfy LC101 and LC104.
>>>
>>>-----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 20:11:15 UTC