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 Thursday, 7 July 2005 17:36:14 UTC