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

Amy,

The proposal makes the Component Model more self consistent and helps to 
make the formal specification clearer.

In all Components, except Interface, the {properties} and {features} 
properties are directly mapped to the Infoset, i.e. they are the children 
Feature and Property components. However, in Interface, they are derived. 
In Interace, they are the children Feature and Property components and 
those of all the extended Interfaces. I find this inconsistent.

We really have two concepts here. One is the children Feature and Property 
components, and the other is the in-scope Feature and Property components. 
This is very analogous to namespace attributes in the Infoset. In Infoset 
there are two properties:
1. [namespace attributes]
2. [in-scope namespaces]

The [in-scope namespaces] are computed from the [namespace attributes] of 
the element and the [in-scope namespaces] of the parent.

I recommend that we use a consistent naming convention for the properties:

1. {features} and {properties} are always the children Feature and 
Property components
2. {in-scope features} and {in-scope properties} include those from the 
parent and, for Interface components, those from the extended Interface 
components

I think it is clearer to give distinct names to different concepts.

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/



Amelia A Lewis <alewis@tibco.com> 
Sent by: www-ws-desc-request@w3.org
01/28/2005 12:25 PM

To
Arthur Ryman/Toronto/IBM@IBMCA
cc
www-ws-desc@w3.org
Subject
Re: Proposed Changes to the Interface Component, Features and  Properties







Arthur,

Could you explain, please, why this separation is needed or useful (and
which: is it *necessary* for a formal description, or does it simplify
that description?), in more detail?

My mental model of scoped things in XML tends to associate with xmlns
(not, perhaps, the most attractive of examples, but as close to a
canonical, scoped semantic that is likely to be understood by all XML
tweakers as anything I can think of).  In the infoset model of
namespaces, I think, namespaces are simply there, and you discover
whether they were defined at a particular point by looking up the tree. 
No?  Infoset 2.11:

Each element in the document has a namespace information item for each
namespace that is in scope for that element.

But no division between these namespace information items and
(hypothetical) namespace declaration information items.

Amy!
On Thu, 27 Jan 2005 10:04:22 -0500
Arthur Ryman <ryman@ca.ibm.com> wrote:

> 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/


-- 
Amelia A. Lewis
Senior Architect
TIBCO/Extensibility, Inc.
alewis@tibco.com