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

Received on Friday, 28 January 2005 17:25:52 UTC