W3C home > Mailing lists > Public > public-ws-addressing@w3.org > July 2005

Re: LC 104 and the abstract info model for EPRs

From: Prasad Yendluri <pyendluri@webmethods.com>
Date: Mon, 11 Jul 2005 12:00:06 -0700
Message-ID: <42D2C1B6.7050209@webmethods.com>
To: Anish Karmarkar <Anish.Karmarkar@oracle.com>
CC: Jonathan Marsh <jmarsh@microsoft.com>, "Nilo Mitra (TX/EUS)" <nilo.mitra@ericsson.com>, tom@coastin.com, public-ws-addressing@w3.org

IMHO we do not need an exaustive specification of extensibility at the 
abstract information model level.
Perhaps a simple statement to the extent of

"The information model of an end point reference is extensible in that 
additional properties and attributes on the properties may be added.  
See the XML Infoset model section for a formal specification of the 
extensibility points at the XML Infoset level.",

would have been enough.

Regards, Prasad

Anish Karmarkar wrote:

>
> Prasad Yendluri wrote:
>
>> Anish,
>>
>> Anish Karmarkar wrote:
>>
>>> Prasad,
>>>
>>> I'm not sure I understand your comment.
>>>
>>> The proposal does not say that we should get rid of Infoset. It says 
>>> that we describe things only in terms of Infoset rather than an 
>>> abstract model and an infoset representation. I.e., it does not say 
>>> that things are described in terms of "<", ">".
>>
>>
>>
>> I was not at all suggesting that your proposal is asking to get rid 
>> of Infoset section . My point was that Infoset description is still a 
>> natural language description of a (well-formed) XML document. It is 
>> still a description of the layout the bits in a document.  I do not 
>> see in principle an issue with supplemental descriptions that provide 
>> conceptual insights. Personally I found the Informational Model 
>> sections useful.
>>
>
> Ok, understood.
>
> Although, I don't agree that Infoset is the description of the layout 
> of the bits in the document. For example, Oracle has a serialization 
> of infoset in the database -- the infoset does not describe the layout 
> of the bits in that serialization.
>
> Having the abstract model, in the case of EPRs, raises interesting 
> questions about extensibility and mapping of the Infoset to the 
> abstract model (issues LC101 and LC104) -- which I'm not sure how to 
> address. Do you have suggestions on how to address them.
>
> -Anish
> -- 
>
>> Prasad
>>
>>> -Anish
>>> -- 
>>>
>>> Prasad Yendluri wrote:
>>>
>>>> Though I certainly see the merit to the duplication argument, IMO 
>>>> Infoset is a formal description of XML representation (it is XML 
>>>> Infoset after all). I personally find a conceptual description 
>>>> always useful over describing things from strict layout of bits 
>>>> angle only.
>>>>
>>>> Regards, Prasad
>>>>
>>>> ------- Original Message --------
>>>> Subject:     RE: LC 104 and the abstract info model for EPRs
>>>> Resent-Date:     Fri, 08 Jul 2005 18:19:28 +0000
>>>> Resent-From:     public-ws-addressing@w3.org
>>>> Date:     Fri, 8 Jul 2005 11:18:33 -0700
>>>> From:     Jonathan Marsh <jmarsh@microsoft.com>
>>>> To:     Nilo Mitra (TX/EUS) <nilo.mitra@ericsson.com>, 
>>>> <tom@coastin.com>, Anish Karmarkar <Anish.Karmarkar@oracle.com>
>>>> CC:     <public-ws-addressing@w3.org>
>>>>
>>>>
>>>> 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.
>>>>
>>>> -----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:01:17 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:35:06 GMT