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.html?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:08:47 UTC