sca-assembly message

Subject: Re: [sca-assembly] NEW ISSUE (1.2): Business data filter element needsbetter name, definition

From: Peter Niblett <peter_niblett@uk.ibm.com>
To: Eric Johnson <eric@tibco.com>
Date: Wed, 22 Sep 2010 16:18:47 +0100

Eric

At the start of the section we explain that three things that the filter syntax has to express.

1. The type of data that the filter operates against (the “subject”)

2. The language used to express the filter (the “dialect”)

3. The filter expression itself.

It is helpful to retain the separation of 1 and 2, as it allows you to tell what the subject is, even if you don't recognise the dialect. If we just had a flat name I could define my own filter expression - say Peter_special_no_22 - and it would not be possible to tell what kind of filter it is. Also if you do a have a dialect used for more than one subject (e.g. XPath used for both body and metadata) you only have to define its syntax and semantics once.

I actually prefer a syntax where the dialect is expressed as an attribute (that's what happens in WS-Notification and WS-Eventing), e.g.

but we felt that since the . convention is used elsewhere in SCA to express this kind of thing, it would be natural to use that here. Hence we have

<body.xpath1> A/B </body>

Having said that. we made a special case of the event type filter, as we think that is going to be used a lot, and that has a default dialect (the QName match dialect explained in the text) which does not need to be specified explicitly

Now looking at the features of this that you commented on

a) You don't see the need to put xpath1 in, and point out that there are other places where XPath 1.0 expressions appear in SCA. I would say that the other places are different, since XPath 1.0 is adequate in the other places where it used (so there's no need to allow other versions). I do want to make sure we have an extensibility point here to allow the use of other body filter languages, in particular XPath 2.0 since it supports XML Schema datatypes, so you can do things like dateTime comparisons in a filter. It's also used in XQuery (however we felt we could not edict XPath 2.0 as the only way to do body filters.

You could make the case that xpath1 should be the default for body filters (so <body> implies XPath 1.0, and to get 2.0 you use <body.xpath2> ) but over time that might leave us with an out-of-date default, so I would suggest we stick with the current formulation.. though I think we should change the spelling to XPath1.

b) You think <body> is too generic a name, and prefer <eventBodyFilter>. If we were to do this, then we would need to change the names of the other filters to match, e.g. eventTypeFilter and eventMetadataFilter

Part of our motivation here was to try and avoid longwinded names. There isn't any point putting Filter in, as these things all appear as children of an element called <filters>, and these things are all about Events, so why put that in all of them?

I'd personally be happy with putting Event in each of them, as it does make the names more explanatory... at the moment we have filters/type which makes it look a bit as if it is a type of filter, rather than a filter that filters on an event type.

While we are discussing this, the word "body" is a bit strange and does suggest some kind of messaging envelope. In WS-Notification we used "messageContent" but I can see that isn't quite right. Assuming we put the Events in, we could have "eventData" for this one and "eventMetadata" for the next one. What do you think?

Finally you draw attention to the strange sentence "Context Node: the root element of the document being searched based upon the subject.". This was left over from an earlier draft, where the XPath dialects were being described independently from the subject that they were being used for, in a separate part of the document. It was felt that it would be clearer to understand if we put the description of the dialect inline at the first place where it is used, but unfortunately this sentence got left in. So I am happy with the change you suggest to this.

Regards

Peter Niblett
IBM Senior Technical Staff Member
Member of the IBM Academy of Technology
+44 1962 815055
+44 7825 657662 (mobile)

From: Eric Johnson <eric@tibco.com>
To: OASIS SCA Assembly <sca-assembly@lists.oasis-open.org>
Date: 22/07/2010 20:12
Subject: [sca-assembly] NEW ISSUE (1.2): Business data filter element needs better name, definition

Target assembly-1.2 WD01 (PDF, regular form, not diff) Description: In section 9.3.1 The current name of the Business data filter element has an extremely generic name of "body.xpath1" - this is not a useful name for describing what it does, and putting xpath1 in the name is inconsistent with the other places where XPath applies (properties) and presumably has a version. Also, the description says the context node is : "Context Node: the root element of the document being searched based upon the subject. In this case (the Business Data Subject) it is the root element of the event business data." Assuming that the business data element is the root element of the transport payload is confusing, because it could be nested under some enveloping scheme (SOAP, anyone?) So it would seem that "root element of the document", and "root element of the event business data" can mean two different things. Proposal: Change the name of the filter to eventBodyFilter. Change the description of the Context Node to: "The root element of the event business data." --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at:https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU