RE: LC 104 and the abstract info model for EPRs

> -----Original Message-----
> From: Anish Karmarkar [mailto:Anish.Karmarkar@oracle.com]
> Sent: Monday, July 11, 2005 10:23 AM
> To: Jonathan Marsh
> Cc: Nilo Mitra (TX/EUS); tom@coastin.com; public-ws-addressing@w3.org
> Subject: Re: LC 104 and the abstract info model for EPRs
> 
> Jonathan Marsh wrote:
> > 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.
> >
> 
> Yes, that was one of the intentions for changing the EPR section.
> 
> Pl. note that, I had assumed that if the WG accepted the direction of
> the proposal, the editors would change things to make it sound better,
> make clarifications, etc.

I had assumed that also, but I think there are other (non-editorial)
terminological changes that might pop up.

> I grepped for 'value' in section 2, but did not find it. Did you mean
> section 2 (or a subsection in it) or some other section?

Oops, meant Part 2.  I meant occurrences of 'value' such as "The value
of each message addressing property that is of type IRI MUST be
serialized as an absolute IRI in the corresponding SOAP header block."
That would take some reconstructive surgery.

> > 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 could not get away from using the term 'properties'. Unlike an EPR,
> MAPs are a collection of things which don't have a single (container)
> representation or an "identifier". Since we need a term to refer to
the
> collection of things that augment the message it made sense to retain
> the term MAP.
>
> The way I see it is that these are properties which are identified by
> QNames. For example, the 'wsa:Action' property. I find that simpler
than
> saying the [action] property which is mapped to wsa:Action EII.

Well, we'll have to disagree.  I think talking about an wsa:Action
property is messier because "wsa:Action property" is too similar to
"wsa:Action".

> > 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?
> 
> Isn't that true even when you say:
> "[relationship] property has a value of 'mid:***'"
> wsa:RelatesTo is a complex structure, just saying that it has a value
of
> 'mid:***' makes it ambiguous regardless of what you call it.

No.  We define the mapping from the XML Infoset to [relationship]
precisely so I know just what that means.

> > Does
> > wsa:RelatesTo mean the property or the structure, or is it a
structured
> > property?
> 
> "wsa:RelatesTo" is an EII. "wsa:RelatesTo property" is an MAP which is
a
> structured property (similar to [relationship] property as it stands
> right now).

The separation of these concepts is not made clearly in your proposal.
I believe distinguishing these concepts would undo much of the
"simplification" you desire.  For instance, I don't see you can collapse
the sections as you've done.

> > 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.
> >
> 
> Are you suggesting that the name of the property and the EII has to be
> different? They are certainly distinct. For example, wsa:Action EII
may
> be used, say, as part of the SOAP payload -- in which case, it is just
> payload and has no bearing on the wsa:Action MAP of that message
(which
> will depend on value of the SOAP header wsa:Action). But it does not
> seem like this requires calling it [action] property as opposed to
> wsa:Action property. But if calling it [action] makes sense, that
would
> be fine too. My goal was to remove the abstract section and say that
> this is all Infoset.

I don't get it.  You say it's distinct, but then also say you want to
remove the abstract section.  Aren't those contradictory statements?

> I don't particularly care whether it is called "wsa:Action property"
or
> "[action] property", it just seems simpler to call it wsa:Action
property.

You have done more than just rename.  But even if that's all you want to
do, I'd rather keep the current names.

> > 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:31:51 UTC