Subject: [Simple] RE: WGLC: draft-ietf-simple-filter-format-01.txt

From: [email-masked]
Date: Fri, 16 Jul 2004 12:44:02 +0300

Paul,

Thanks for taking the time to review the drafts. Responses inline..

> -----Original Message-----
> From: ext Paul Kyzivat [mailto:[email-masked]]
> Sent: 13.July.2004 19:11
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki)
> Cc: [email-masked]
> Subject: Re: WGLC: draft-ietf-simple-filter-format-01.txt
> 
> 
> Hisham,
> 
> The following are comments on the draft in response to your 
> request for 
> a review. Please take these with a grain of salt - I haven't been 
> following the work (just for lack of time), and I don't know 
> much about 
> XPath either, on which this is based. Feel free to push back if these 
> comments are misguided.
> 
> 	Paul
> 
> General comment:
> 
> I don't know whether to join this argument or not, but I see 
> that this 
> document uses extensive normative language that is redundant 
> with what 
> the xml schema defines. I am somewhat inclined to agree that the xml 
> should be authoritative and so text descriptions should use 
> non-normative language for things covered by the schema. But 
> I would be 
> happy if this document follows whatever approach is generally 
> considered 
>   the WG (or ietf) sanctioned approach.

In the working version that I have now, I have removed all the normative text (the MUSTs and SHOULDs). I believe there was consensust to have informative text.

> 
> Section 3.2:
> 
> Says may have uri or domain element. Says domain defines the 
> domain of 
> the resources the filter applies to. I think I know what that 
> means, but 
> it would be nice to be more explicit - namely that it selects 
> resources 
> whose uri is a sip uri with a matching domain part.
> 
> Says:
>     The URI attribute MAY also carry a domain.  In this case, 
> the filter
>     applies to resources in that domain.
> 
> I *think* this means to say "the <filter> may carry a 
> domain", refering 
> to the 'domain' attribute. But I am far from sure of this 
> based on the 
> text.

Good catch. This text is old. In an earlier version, there was no 'domain' attribute. I'll clarify. Changed to "The 'domain' attribute carries a domain. In this case, the filter applies to resources who's URI has a domain part matching that domain."

> *If* that is the case then it partially resolves my 
> prior comment. 
> But not fully, because it still doesn't define what 
> "resources in that 
> domain" means. I presume this is all about full or partial 
> text matching 
> against URIs. Given that different kinds of URIs have 
> differing matching 
> rules, this whole subject deserves more explanation.

Added some text about this issue.

> 
> The description of the <filter> element *does* include normative text 
> that isn't in the schema - namely that there must be at least one of 
> <what> and <trigger>. While I don't know enough xml to say how, I 
> suspect there is a way to describe this case in the schema. If so, it 
> would be preferable to do so. (In English, I think you could define a 
> type consisting of a sequence of 0 or 1 <what> and 0 or 1 <trigger>. 
> Then you could define <filter> to contain 1 or more of that type.)

The problem here is that a maximum of only one <what> element is allowed, while <trigger> element occurence is unbounded. I don't think this restriction can be done with the schema.

> 
> Section 3.3:
> 
> says:
>     The <what> element MAY contain one or more <include> 
> elements and one
>     or more <exclude> elements.  However, the <what> element 
> MUST contain
>     at least one <include> element.  When more than one 
> <include> element
>     has been defined, the result is the union of all the <include>
>     elements.  When more than one <exclude> element has been 
> defined, the
>     result is the union of all the <exclude> elements.
> 
> This isn't entirely clear, especially when there are both 
> <include> and 
> <exclude> elements. It isn't really possible to define the 
> meaning here 
> because it isn't yet clear what "union" applies to. In 
> reality I think 
> you are operating on trees, not sets, so set operations don't really 
> apply. Are suitable semantics for this available in XPath? I 
> think the 
> semantics are *reasonably* obvious intuitively, but the 
> challenge is to 
> define them normatively.

I removed the use of the word "union". The text now reads:

The &lt;what&gt; element MAY contain one or more &lt;include&gt; elements and one or more &lt;exclude&gt; elements.  When more than one &lt;include&gt; element has been defined, the results are additive. I.e. each &lt;include&gt; element contents adds an element or attribute to the resulting XML document.  When more than one &lt;exclude&gt; element has been defined, each value it each &lt;exclude&gt; element depletes  the contents of the resulting XML document.

> 
> Says:
>     When identifying XML elements, the value may consist of two parts
>     (similar to XPath [9]): the XML element selector and the condition
>     (comparison and logical expressions).  The syntax is defined in
>     section Section 4 (see the definition of "selection".)
> 
> The exact relationship to XPath is confusing. Is there a normative 
> relationship? The reference indicates yes, but exactly what is drawn 
> normatively from it, rather than being copied and subsetted? 
> It appears, 
> here and in later sections, that the syntax is being 
> redefined, but the 
> semantics is being referenced. This could be a lot clearer.

Section 4 has more about this issue. I moved any text talking about xpath to that section, with more clarifications.

> 
> Section 3.3.2
> 
> Not clear how <exclude> interacts with the rule that <include> must 
> include other mandatory elements:
> 
> - what if <exclude> references something that is 
> unconditionally mandatory?
> 
> - what if <exclude> references a mandatory sub-element of an optional 
> element that is referenced by <include>?

I had noticed the lack of text on these these issues already and added some text.

> 
> Says:
>     The <exclude> element MUST NOT be used if there are no <include>
>     element(s) in the same content filter.
> 
> But an <include> element is mandatory. So this is moot.

I recently received a comment that it might be useful for <exclude> to appear alone without <include>.

> 
> Section 3.4.1:
> 
> Says:
>     The <changed> element is used to identify the XML element or
>     attribute, from the package specific XML document, that 
> must change,
>     compared to the previous XML document,
>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> How is 'previous XML document' defined? Is it replaced each time an 
> update to the document is received? Or for a particular 
> subscriber, is 
> it the version last selected for delivery to the subscriber?

it is the version last selected for delivery to the subscruber before the filter was applied. I say "before the filter was applied" because the include and exclude expression might have caused the referenced element not to be delivered. I'll clarify.
> 
> Apparently the <changed> element needn't contain any of changed-from, 
> changed-to, or changed-by. I suppose that means it just tests for 
> changes of any sort. Is that what is intended? In that case, what 
> constitutes a change? Must the value be updated with a *different* 
> value, or simply be updated, possibly with an identical value?

Well, updated with the same value is not really a change in value, is it? I'll add text.

> 
> For <changed> without attributes, or with changed-from or changed-to, 
> how is the comparison done? Is it literal string comparison, or type 
> specific comparison? (If type specific, what if the type is 
> unknown to 
> the server? (Consider a case where an element containing a URI is 
> changed from "sip:foo@bar" to "sip:foo@BAR".)

For simplicity,  lets make it a string comparison.

> 
> Is there a constraint on the type of element that changed-by 
> is applied 
> to? Must it be decimal? Must the change be in a particular direction?

Any numberical value.  It doesn't necessarily have to be decimal. A change in any direction is a change. I'll add text.

> 
> Section 5.4:
> 
> I find this example inconsistent with my understanding of the uri 
> attribute. I thought it acted as a restriction on what the filter 
> applies to. In this case I would expect that the subscription itself 
> would have been addressed to sip:[email-masked], and the uri 
> parameter used only to restrict a filter to a particular 
> buddy in the list.
> 
> Section 5.6:
> 
> I have the same problem here as in 5.4, but it is even 
> clearer, because 
> the uri attribute is sued both ways. AFAIK there never is a presence 
> document for sip:[email-masked] - only ones for each of 
> the buddies. 
> So the uri attribute shouldn't match anything.
> 
> Section 6 (schema):
> 
> The attribute 'domain' of <filter> is of type 'anyURI'. While I am an 
> xml neophite this seems wrong.
> 

Changed to string.

Thanks,
Hisham

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple