LC 104 and the abstract info model for EPRs

I took an action item to kick off a discussion on LC 104.

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