Issue 6917: preliminary proposal for Event Tags; tag values

In our previous emails on this subject ([1], [2]) we have been using 
Event Tag values that are simple strings like "weather" and "wind". This 
has a number of obvious disadvantages, the primary of which is the 
potential for collisions (e.g. in situations where the Event Source is 
acting as an intermediate for other Event Sources that may not be aware 
of each other). Like Namespaces in XML, it makes sense to leverage DNS 
to support the creation of unique tags without requiring some kind of 
central tag registry. In other words, *Event Tags should be URIs*. The 
previous EventDescriptions example would then look like this:

<wse:EventDescriptions 
targetNamespace="http://www.example.org/oceanwatch/notifications"
                       xmlns:wse="http://www.w3.org/2009/02/ws-evt"
                       xmlns:ow="http://www.example.org/oceanwatch"
                       xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <wse:types>
    <xs:schema targetNamespace="http://www.example.org/oceanwatch">
      <xs:include schemaLocation="oceanwatch.xsd"/>
      <xs:element name="WindReport" type="ow:WindReportType"/>
      <xs:element name="RainReport" type="ow:RainReportType"/>
    </xs:schema>
  </wse:types>

  <wse:eventType name="WindReport"
                 element="ow:WindReport"
                 action="http://www.example.org/oceanwatch/2003/WindReport">
*    <wse:eventTag>http://www.example.org/tags/weather</wse:eventTag>
    
<wse:eventTag>**http://www.example.org/tags/weather/**wind</wse:eventTag>*
  </wse:eventType>
  <wse:eventType name="RainReport"
                 element="ow:RainReport"
                 
action="http://www.example.org/oceanwatch/2003/RainReport"/>
*    <wse:eventTag>**http://www.example.org/tags/weather**</wse:eventTag>
    
<wse:eventTag>**http://www.example.org/tags/weather/**rain</wse:eventTag>*
  </wse:eventType>
  . . .
</wse:EventDescriptions>

The important point is that whomever controls the "www.example.org" 
domain is responsible for any http Event Tags defined in that domain. 
Like XML namespace declarations, you shouldn't create tags with domains 
that don't belong to you. Also, to the extent that tags identify a 
resource (the set of all Event Types that share that  tag), the use of 
URIs to identify these resources is consistent with W3C architecture [3].

Finally, the use of URI schemes with hierarchical paths (e.g. http, ftp, 
etc.) allows for the definition of "hierarchical tags". It's not clear 
to me that the benefits of defining such a thing outweighs the increase 
in complexity, but we /could /define Event Tags such that the tag 
"http://www.example.org/tags/weather" encompassed the tags 
"http://www.example.org/tags/weather/wind", 
"http://www.example.org/tags/weather/rain", and any 
"http://www.example.org/tags/weather/*" that might be used. The above is 
then more simply expressed as:

  <wse:eventType name="WindReport"
                 element="ow:WindReport"
                 
action="http://www.example.org/oceanwatch/2003/WindReport">*   
    
<wse:eventTag>**http://www.example.org/tags/weather/**wind</wse:eventTag>*
  </wse:eventType>
  <wse:eventType name="RainReport"
                 element="ow:RainReport"
                 
action="http://www.example.org/oceanwatch/2003/RainReport"/>
***    
<wse:eventTag>**http://www.example.org/tags/weather/**rain</wse:eventTag>*
  </wse:eventType>
  . . .

Hierarchical tags have obvious uses in the realms of system management, 
etc. which is why this concept appears in many other places (e.g. 
WS-Topics).

[1] 
http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jul/0093.html
[2] 
http://lists.w3.org/Archives/Public/public-ws-resource-access/2009Jul/0094.html
[3] http://www.w3.org/TR/webarch/

- gp