Re: LC 104 and the abstract info model for EPRs

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.

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 17:48:38 UTC