RE: Proposed Changes to the Interface Component, Features and Properties

Thank you for your comment - we tracked this as a Last Call comment
LC104 [1].  The Working Group agreed to make Interface {features} and
{properties} consistent, per [2].  The WG declined to add {in-scope
properties} or {in-scope features}.  WG agreed to "change the definition
of the above properties to include only those components that are
directly defined in the Interface", but declined to add {all operations}
and {all faults} properties.

 

If we don't hear otherwise within two weeks, we will assume this
satisfies your concern.

 

[1] http://www.w3.org/2002/ws/desc/4/lc-issues/issues.html#LC104

[2] http://lists.w3.org/Archives/Public/www-ws-desc/2005Feb/0068.html

 

 

________________________________

From: www-ws-desc-request@w3.org [mailto:www-ws-desc-request@w3.org] On
Behalf Of Arthur Ryman
Sent: Thursday, January 27, 2005 7:04 AM
To: www-ws-desc@w3.org
Subject: Proposed Changes to the Interface Component, Features and
Properties

 


This proposal is a follow-on to my note [1]. 

The {operations}, {faults}, {properties}, and {features} properties of
the Interface component are defined as derived properties rather than as
being directly mapped onto the XML infoset. 

The {operations} and {faults} include the Operation and Fault components
directly defined in the Interface component and those inherited from any
Interface components that this component extends. 

The {features} and {properties} similarly include all directly defined
and inherited Feature and Property components. 

I recommend that we change the definition of the above properties to
include only those components that are directly defined in the
Interface, and introduce another set of derived properties that are
computed from the directly defined properties as follows: 

{all operations} and {all faults} include those directly defined and
those inherited from extended Interface components. 

{in-scope features} and {in-scope properties} include those directly
defined, those inherited from extended Interface components, and those
included from parent components. This is analogous to the [in-scope
namespaces] property of the XML Infoset [2]. 

Furthermore, we should add {in-scope features} and {in-scope properties}
to all components that have {features} and {properties}. 


The benefit of these changes is that we have a clear and consistent
naming convention for directly defined properties versus derived
properties. 

Editorially, we do not have to update the description of each affected
component. We could just add a section that defined the meaning of
{in-scope features} and {in-scope properties}. 

[1]
http://lists.w3.org/Archives/Public/public-ws-desc-comments/2005Jan/0007
.html 
[2] http://www.w3.org/TR/xml-infoset/ 

Arthur Ryman,
Rational Desktop Tools Development

phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@fido.ca
intranet: http://labweb.torolab.ibm.com/DRY6/