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 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?

> 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.

> 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.

> 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).


> 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 particularly care whether it is called "wsa:Action property" or 
"[action] property", it just seems simpler to call it wsa:Action property.

> 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 17:23:28 UTC