RE: LC101/LC104 - proposed text

Sorry, misunderstood your concern and went off the deep end!

 

________________________________

From: Prasad Yendluri [mailto:pyendluri@webmethods.com] 
Sent: Monday, July 18, 2005 10:42 AM
To: Jonathan Marsh
Cc: Glen Daniels; public-ws-addressing@w3.org
Subject: Re: LC101/LC104 - proposed text

 

Jonathan,

Jonathan Marsh wrote:



So, you'd like to see a framework for handling such attributes?  I think
what you're asking for is something like a general purpose:

 

  [address] (IRI, subproperties?)

I am not at all asking that we introduce anything new (new framework or
such). As I stated below all I like to see is a description in the
Information model of the extensibility model that matches what is shown
at the XML Infoset model (to satisfy LC 101).  The current proposal on
that table seems incomplete from the aspects I described below.

Lest we go off on a tangential thread, let us discuss this in the f2f
meeting today. 

Prasad



Seems like I have lots of flexibility now and I'm not sure a structured
property framework is necessary.  For instance, say I add a an attribute
to wsa:Address as follows:

 

  <wsa:Address fallback="mailto:backup@example.com"
<mailto:backup@example.com>
>http://example.com/webservice/preferred</wsa:Address>

 

(Pretty sure the example is complete nonsense, but bear with me
nonetheless.)  I could represent the new information content by
modifying the original [address] property to accommodate both:
[address] (IRI, IRI?), or I could introduce a new property who's
semantics tie it to the Address: [backup-address] (IRI?) or I could
introduce a new property which encodes the link between the two values
more explicitly, e.g. [all addresses] (IRI, IRI?).  Some of these
choices might be better than others, but the extension author makes that
decision, not us.

 

It would also seem strange to architect a framework for attributes that
doesn't also accommodate subelements, which would further complicate the
design.

 

________________________________

From: Prasad Yendluri [mailto:pyendluri@webmethods.com] 
Sent: Friday, July 15, 2005 2:48 PM
To: Jonathan Marsh
Cc: Glen Daniels; public-ws-addressing@w3.org
Subject: Re: LC101/LC104 - proposed text

 


Jonathan Marsh wrote:




What do you mean by "attributes on properties"?  I understand attributes
on elements.  And I understand properties can have structured values.
But I'm not sure which you mean, or something else.

To be really complete in our description of the extensibility model at
the Information Model (abstract properties) level, we need to capture
the equivalent of the Attribute Information Item based extensibility
points shown in the XML Infoset representation section (@{any}).  I did
not see that come across in the text proposed by Glen. 

Agree we will need to phrase this appropriately but I don't see a
conflict of interest :) in using the XML terminology like attributes as
the Information Model section already uses other XML things like
defining 

[reference parameters] :  xs:any  (0..unbounded) 
and description of which states "Reference parameters are element
information items.."

Additionally the XML Infoset Model shows: 

/wsa:EndpointReference/wsa:Address/@{any}
/wsa:EndpointReference/wsa:ReferenceParameters/@{any}
/wsa:EndpointReference/@{any}

So, the AII based extensibility is shown directly on the "equivalent" of
a property.

Finally current proposal from Glen says 

>This specification defines a core set of properties, but it is also
possible
>for other specifications to extend these with other properties.

This does not capture the extensibility of the core properties (already
defined in WS-A) itself.
I would like to see that captured as well.

Regards,

Prasad

-------- Original Message -------- 

Subject: 

Re: LC101/LC104 - proposed text

Resent-Date: 

Thu, 14 Jul 2005 01:35:14 +0000

Resent-From: 

public-ws-addressing@w3.org

Date: 

Wed, 13 Jul 2005 18:33:50 -0700

From: 

Prasad Yendluri <pyendluri@webmethods.com>
<mailto:pyendluri@webmethods.com> 

To: 

Glen Daniels <gdaniels@sonicsoftware.com>
<mailto:gdaniels@sonicsoftware.com> 

CC: 

public-ws-addressing@w3.org

 

Glen,
 
This is pretty good. The proposed text does not seem to cover 
modification via extension of the abstract properties  already defined 
in section 2.1 (core-properties).  Was that intentional? Section 2.2 XML

Infoset Representation explicitly shows it as allowed.
 
Also do we need to speak to extension attributes on properties? I had it

covered in my original proposal as below..
 
"The information model of an end point reference is extensible in that 
additional properties and attributes on the properties may be added.  
See the XML Infoset model section for a formal specification of the 
extensibility points at the XML Infoset level.",
 
Regarding the pseudo-schema in  XML infoset section not showing the 
{any} element and the @{any} attributes, this was flagged in the LC 
issue I raised 
http://lists.w3.org/Archives/Public/public-ws-addressing-comments/2005Ap
r/0002.html
 
Thanks, Prasad
 
Glen Daniels wrote:
 
>Hi folks:
> 
>Here's an amended proposal for LC101/104.  Replace first sentence in
>section 2.1 with:
> 
>---
>An endpoint reference is a collection of abstract properties.  This
>specification defines a core set of properties, but it is also possible
>for other specifications to extend these with other properties.  The
>semantics and XML Infoset representation (see next section) for any
such
>extension properties will be described in their defining
specifications.
> 
>The core properties are as follows:
>---
> 
>With regard to the XML infoset section, I notice that we're missing
>pseudo-schema for the {any} element and the @{any} attribute - I think
>we should add that.  Then, after the last
>"/wsa:EndpointReference/@{any}" definition and before the example, we
>should add:
> 
>---
>NOTE: Specifications which describe any extension elements or
attributes
>used to augment the above model will explain any effects those
>extensions may have on the abstract properties.  They may affect either
>the core properties or extension properties as defined in section 2.1.
>---
> 
>I think this gets across what we discussed on Monday.
> 
>Thanks,
>--Glen
>