[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Simple] RE: WGLC: draft-ietf-simple-filter-format-01.txt
Paul,
Thanks for taking the time to review the drafts. Responses inline..
> -----Original Message-----
> From: ext Paul Kyzivat [mailto:pkyzivat at cisco.com]
> Sent: 13.July.2004 19:11
> To: Khartabil Hisham (Nokia-TP-MSW/Helsinki)
> Cc: simple at ietf.org
> 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 <what> element MAY contain one or more <include> elements and one or more <exclude> elements. When more than one <include> element has been defined, the results are additive. I.e. each <include> element contents adds an element or attribute to the resulting XML document. When more than one <exclude> element has been defined, each value it each <exclude> 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 at bar" to "sip:foo at 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:buddylist at domain.com, 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:buddies at domain.com - 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
Simple at ietf.org
https://www1.ietf.org/mailman/listinfo/simple