Subject: RE: [Simple] WGLC: Event Filtering

From: [email-masked]
Date: Wed, 7 Jul 2004 16:40:13 +0300

Miguel,

Thanks for the comments. Responses inline...

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]]On Behalf
> Of ext Miguel Garcia
> Sent: 05.July.2004 15:46
> To: Robert Sparks
> Cc: Costa-Requena Jose (Nokia-TP/Helsinki); Khartabil Hisham
> (Nokia-TP-MSW/Helsinki); [email-masked]; Lonnfors Mikko
> (Nokia-NRC/Helsinki); Leppanen Eva-Maria (Nokia-NET/Tampere)
> Subject: Re: [Simple] WGLC: Event Filtering
> 
> 
> Hi:
> 
> I am sorry for the long e-mail... Here are some comments to the 
> filter-format-01.txt draft.
> 
> 
> 
> - Section 3, first paragraph reads:
> 
>     The filter criteria is an XML document [8] that MUST be 
> well-formed
>     and MUST be valid.  The filter criteria XML documents 
> MUST have the
>     XML declaration and it SHOULD contain an encoding 
> declaration in the
>     XML declaration, for example; "<?xml version='1.0'
>     encoding='UTF-8'?>".
> 
> First problem, why the document 'MUST be valid'? In other XML 
> documents
> created by SIMPLE the statement reads 'SHOULD be valid'. So why the
> strength is higher in Filter Criteria documents?

Ok, changed to SHOULD.

> 
> Second problem. I don't understand the value of the above 
> sentence: 'XML
> document MUST have the XML declaration' (of course, they are XML
> documents) and 'SHOULD contain an encoding declaration'... 
> but you don't
> say what the encoding should be, so there is not point in 
> indicating the
> encoding declaration if you don't restrict it to some values. My
> proposal is to align this statement with the rest of the XML documents
> that SIMPLE is producing, and replace the above sentence with:
> 
>     A filter criteria is an XML [3] document that MUST be
>     well-formed and SHOULD be valid. Filter criteria documents MUST
>     be based on XML 1.0 and MUST be encoded using UTF-8.

Done.

> 
> - Section 3 states:
> 
>     The namespace identifier for elements defined by this 
> specification
>     is a URN [5], using the namespace identifier 'ietf' defined by [6]
>     and extended by [4].  This urn is:
>     urn:ietf:params:xml:ns:simple-filter+xml.
> 
> The namespace should be "urn:ietf:params:xml:ns:simple-filter" rather 
> than "urn:ietf:params:xml:ns:simple-filter+xml".

Fixed.

> 
> - Missing link with the MIME type simple-filter+xml. I didn't 
> fine any 
> linkage to the simple-filter+xml MIME type.
> 
> I am missing some normative text that indicates the following ideas:
> a) This specification defines a new MIME type "simpler-filter+xml".

Added.

> b) Implementations MUST support this MIME type.

Functionality draft issue.

> c) Filter criteria documents MUST be sent setting the Content-Type to 
> "simple-filter+xml".

Functionality draft issue.

> 
> - Namespaces prefixes. There are many elements that accept a namespace
> prefix to identify the correct element. The question is, where is the
> binding between the namespace and the prefix defined? None of the
> examples show this binding, but all of them refer to "pidf", "rpid",
> "wi" namespaces. For instance, this is an excerpt from an example:
> 
>           <simple-filter:include type="xml-element">
>             //pidf:tuple/pidf:status/pidf:basic[rpid:class="IM"
>             or rpid:class="SMS" or rpid:class="MMS"]
>           </simple-filter:include>
> 
> Where is it define that "rpid" refers to either
> urn:ietf:params:xml:ns:pidf:rpid-tuple or
> urn:ietf:params:xml:ns:pidf:status:rpid-status? And to which one?
> 
> I see two possible solutions. One is that you use the regular
> prefix-namespace binding used in XML. The only problem is that this
> binding refers to elements that you use in your XML document. However,
> you want to prefix ***values*** that refer, in turn, to an 
> XML element.
> It is not quite the same thing. For instance, if you want to use rpid
> and pidf, you could use the following <filter-set> element.
> 
> <filter-set xmlns:n="urn:ietf:params:xml:ns:simple-filter"
>      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>      xsi:schemaLocation="urn:ietf:params:xml:ns:simple-filter"
>      xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid-tuple"
>      xmlns:pidf="urn:ietf:params:xml:ns:pidf"
>      elementFormDefault="qualified"
>      attributeFormDefault="unqualified">

I don't believe this is the right solution. As you said, those apply to qualifying elements not values of elements.

> 
> The other solution is that you explicitly define some XML <binding>
> element as part of your schema. This will be used to define 
> the binding
> you use later. Something like:
> 
> <filter-set xmlns:n="urn:ietf:params:xml:ns:simple-filter"
>      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>      xsi:schemaLocation="urn:ietf:params:xml:ns:simple-filter"
>      elementFormDefault="qualified"
>      attributeFormDefault="unqualified">
> 
>      <binding xmlns:rpid="urn:ietf:params:xml:ns:pidf:rpid-tuple"/>
>      <binding xmlns:pidf="urn:ietf:params:xml:ns:pidf"/>

This works. I used 

<ns-bindings>
  <ns-binding prefix="rpid" urn="urn:ietf:params:xml:ns:pidf:rpid-tuple"/>
  <ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/>
</ns-bindings>

Is this acceptable?

> 
> 
> - Section 3.3. The statement 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.
> 
> I would like to understand why at least one <include> element must be
> present. In other words, why can I just have <what> element 
> that simply
> states what I don't want to receive, i.e., a collection of <exclude>
> elements and zero <include> elements.

I guess <exclude> alone works.

> 
> In case something changes in this section, then section 3.3.2 should
> change as well:
> 
>     The <exclude> element MUST NOT be used if there are no <include>
>     element(s) in the same content filter.

Removed.

> 
> - Section 3.3.1.1. The first paragraph is ok, but the remaining of the
> section has nothing to do with the 'type' attribute. I 
> believe the rest
> should be moved to Section 4, as it discusses the syntax.

I moved to section 3.3.1 where <include> is defined.

> 
> - Section 3.4 states:
> 
>     The <trigger> element MAY contain the <changed> element, 
> the <added>
>     element or the <removed>, but MUST contain at least one 
> of the three
>     elements.  Any combination of the 3 elements is possible. 
>  Multiple
>     appearances of those element within a <trigger> element 
> denotes the
>     "AND" operation.  This means that updates to a resource 
> that satisfy
>     ALL of the <changed>, <added> and <removed> elements' 
> criteria within
>     the <trigger> element constitute the content to be delivered.
> 
> Question: is there a case where the <added> and <removed> can appear
> simultaneously? It would mean: send me element <foo> if it is <added>
> and <removed>, which I believe is not possible ever.

The trigger would say send me a NOTIFY when element <foo> was added and element <bar> was removed.

> 
> - Section 3.4.1 states:
> 
>     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, in order to activate the
>     trigger and cause the content to be delivered.
> 
> If I understand correctly, what changes is not the element itself, but
> the value. Can you confirm it?
> 
> If the element changes, then it could be, e.g., because a new optional
> attribute is added or removed. But I believe that you want to say that
> what it has to change is the value, right?
> 
> Can you clarify in the text what is the intention?

Yes, the texts talks about the value. I'll clarify.

> 
> - Section 3.4.1.3 states:
> 
>     A trigger is active when the XML element or attribute 
> identified with
>     the <changed> element has changed by the value indicated by this
>     attribute from a different value.
> 
> So does this element apply to numeric values only? If so, then I guess
> this is either an addition or subtraction with respect the current
> value (not multiply or division). Therefore, I would propose:
> 
>     The 'changed-by' attribute applies only to numerical values and
>     indicates a delta with respect the current value that an attribute
>     or element (identified in the <changed> element) needs to change
>     before it is selected.
> 
>     Example: if the 'changed-by' attribute is set to 2, and 
> the current
>     value of the element/attribute is 6, the element/attribute is
>     selected when it reaches (or exceeds) the value 8 or when it
>     decreases to 4 or lower value.

Done.

> 
> - Section 3.4.2 states:
> 
>     The XML element or
>     attribute is indicated using the syntax defined in 
> Section 4 for the
>     "reference".
> 
> I think you should make the above text normative:
> 
>     The XML element or attribute MUST be expressed using the syntax
>     defined in Section 4 for the "reference" ABNF.

Done.

> 
> - Section 6, extensibility of the XML schema.
> 
> I noticed weird things related to the extensibility of the 
> XML schema. 
> While you provide extensibility for new attributes of most elements, 
> there is no attribute extensibility to the <what> element. 
> Additionally, 
>   I didn't find any possibility to add new elements. I think 
> this should 
> be possible, when it is rational.

I'll fix by allowing extensibility for elements in FilterType and WhatType.
> 
> - Section 6, the "TypeType" definition.
> 
> Currently, the "TypeType" is defined as:
> 
>       <xs:simpleType name="TypeType">
>         <xs:restriction base="xs:string">
>           <xs:enumeration value="xml-element"/>
>           <xs:enumeration value="namespace"/>
>           <xs:enumeration value="token"/>
>         </xs:restriction>
>       </xs:simpleType>
> 
> I believe the "token" value should not be present.

Yes, left from an older version by mistake.

> Second: in 
> the text 
> it is said (a few times) that a filter applies to either an 
> element, an 
> attribute or a namespace. But now the "type" definition only 
> considers 
> values "xml-element" and "namespace". So how I identify an attribute?
> 
> I believe that "xml-element" is sufficient to accommodate attributes, 
> because you will have an XPath expression that clearly distinguishes 
> elements from attributes. So I am not advocating to add a new 
> "attribute" value to the "type" definition, instead I think 
> you need to 
> rename the "xml-element" by something more generic, perhaps 
> "xpath" to 
> indicate that the value of the element is an XPath expression (or a 
> namespace it is so).
> 
> Then probably you need to add some discussion, in the text, 
> to indicate 
> when to use one or the other.

Changed to "xpath".

> 
> - I would like to get your opinion on a new feature. I 
> believe it might
> be interesting to have rules defined and stored in the 
> server, so that I
> can easily activate a filter set or deactivate it. So a filter that is
> deactivated is not in used, although is easily available for future
> reference or enable it at any time.
> 
> I think I would like to see some 'state' attribute in each <filter> or
> <filter-set> elements, so that I can "enable" or "disable" easily a
> filter, without sending the whole <filter-set> to the server.

Sounds interensting, if there are no objections, I will add.

> 
> - Notation. Some months ago we got an agreement on the 
> notation that we
> should be using for XML specifications. I believe the 
> agreement is that,
> whenever we refer to an element, we include it within brackets (e.g.,
> <element>); an attribute is enclosed in single quotes (e.g.,
> 'attribute'); a value is enclosed in quotation marks (e.g., "this is a
> value").
> 
> For instance: the <foo> element contains an optional 'type' attribute
> that can get the value "open" or "closed".
> 
> This facilitates the reading of the specification. So can you please
> revise the document and make the notation consistent according to the
> above rules?

Done.

> 
> - Examples. All the examples should start with a proper XML 
> header, like:
> 
> <?xml version="1.0" encoding="UTF-8"?>
> <filter-set xmlns="urn:ietf:params:xml:ns:simple-filter"
>       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>       xsi:schemaLocation="urn:ietf:params:xml:ns:simple-filter">
> 
> After that, you don't need to prepend each element in the 
> examples with
> a "simple-filter" prefix (that is not even bound anywhere). But this
> requires that you change a bit the XML schema to add the default
> behavior for elements and attributes. So the schema should 
> start with :
> 
> <?xml version="1.0" encoding="UTF-8"?>
> <xs:schema targetNamespace="urn:ietf:params:xml:ns:simple-filter"
>      xmlns="urn:ietf:params:xml:ns:simple-filter"
>      xmlns:xs="http://www.w3.org/2001/XMLSchema"
>      elementFormDefault="qualified"
>      attributeFormDefault="unqualified">
> 
> With this change to the schema, then the examples validate 
> without that
> prefix, and they are easier to read.

Done.

> 
> - Section 5.1, example. Shouldn't the value of the <include> 
> element be
> prepended with "//pidf:presence" to identify the root element of the 
> pidf document?. For example:
> 
>           <simple-filter:include type="xml-element">
>             //pidf:presence/pidf:tuple/pidf:status/
>             pidf:basic[rpid:class="IM" or rpid:class="SMS" or
>             rpid:class="MMS"]
>           </simple-filter:include>

No. // means any element under the root element
> 
> - Section 5.2, example. Missing one slash "/" before the 
> "/pidf:presence".

Not needed // mean any element.

> 
> - Section 5.3, example. Missing double slashes "//" before the 
> "wi:watcher" value in the <include> element.

Fixed.

> 
> Also in this example, is it it correct to have a slash "/" 
> prior to the 
> at sign "@" in :
> 
>             //wi:watcher/@wi:status@status
> 
> At least by following the ABNF I thought it wasn't right.

This is correct syntax and is allowed by the ABNF.

> 
> - Section 5.5, typo in title:
> 
>     s/Include/include

Fixed.

> 
> - Section 3.1, typo in sentence:
> 
>     '... document containing the filter criteria is separated from
>          the events that makes use of it or from the protocol that
>          usually carries it.'
> 
>     s/makes/make
> 
> - Section 8: I would remove the two paragraphs in this subsection
> 
>     A new content type "application/simple-filter+xml" is defined to
>     represent an XML MIME for the filter criteria.
> 
>     This specification follows the guidelines of RFC3023 [7]

I wouldn't ;)

> 
> 
> And I would start section 8.1 with:
> 
>     This specification registers a new MIME type according to the
>     procedures of RFC 2048 [xx] and guidelines in RFC 3023 [yy].
> 
> 
> - Section 8.1: Typo in title:
> 
>     application/simple-filter+xml mime TYPE
> 
> should read:
> 
> application/simple-filter+xml MIME type
> 
> - Section 8.1: Typo.
> 
>     Security considerations: See section 10 of RFC 3023 [7] 
> and section
>     Section 8 of this document.
> 
> should read
> 
>     Security considerations: See section 10 of RFC 3023 [7] 
> and section
>     Section 7 of this document.
> 
> - Section 8.2: The "URN document" is now RFC 3688.

All fixed.

Thanks,
Hisham

> 
> 
> 
> 
> Best regards,
> 
>       Miguel
> 
> Robert Sparks wrote:
> 
> > This is a SIMPLE working group last call for the following drafts:
> > 
> > 
http://www.ietf.org/internet-drafts/draft-ietf-simple-filter-format-01.txt
> http://www.ietf.org/internet-drafts/draft-ietf-simple-event-filter-funct-01.txt
> 
> Please provide comments to the list or chairs by July 16.
> 
> Thanks,
> RjS
> 
> 
> _______________________________________________
> Simple mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/simple
> 

-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Research Center      Helsinki, Finland

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

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

---

From: Miguel Garcia <[email-masked]>
Date: Wed, 07 Jul 2004 17:15:37 +0300

Inline. I have deleted all the items for which we don't need further 
discussion.

- Miguel

> Functionality draft issue.

M.G: I think I expressed myself wrong, because obviously it does not 
make sense that you define a MIME type and in the same document you say 
that implementations MUST suppport it, so I agree with you. But I think 
the text I am looking for is something that indicates that when an 
implementation encodes a Filter Criteria document, it MUST set the 
Content-Type header (or whatever protocol) to simple-filter+xml. Then 
the functionality draft can say that implementations MUST support filter 
criteria documents.

> Functionality draft issue.

No, this is what I said in point b) above, I think this should be stated 
in the filter criteria format.

>   <ns-binding prefix="pidf" urn="urn:ietf:params:xml:ns:pidf"/>

Yes, at least to me.

> I moved to section 3.3.1 where <include> is defined.

I don't think it makes much sense. Basically, most of the section 3.3.1 
speaks about syntax of Xpath expressions, which happens to be the 
subject of section 4. I see a duplication. So you should choose how to 
document it, but make sure you don't repeat "syntax" sections.

> No. // means any element under the root element

Ok, I understand that the current example is OK, but a bit akward I 
would say:

          //pidf:tuple/pidf:status/pidf:basic[rpid:class ...]

So this means: give me all the <basic> elements that are children of 
<status> that are children of <tuple> that are children of *anything* 
else. Although valid, I would just say

          //pidf:basic[rpid:class ...]

meaning: give me all the <basic> elements that are children of anything.

Anyway, it is just an example.

>>    procedures of RFC 2048 [xx] and guidelines in RFC 3023 [yy].

This was a complete one, not only removing two paragraphs, but 
rephrasing with the above text. I am not sure if you missinterpret me.