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">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 <mailto: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 <mailto: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/2005Apr/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
>
>>  
>
>  
>