Restrictions in XML Representations...?

View: New views
2 Messages — Rating Filter:   Alert me  

Restrictions in XML Representations...?

by Emmanuel Mulo :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Dear All,

While attempting to use XML event representations for the Esper event
processing engine, I run into an issue that I decided to post about
incase somebody else has the same.

Esper has the possibility to represent events as XML documents and
performs the processing on the various elements and attributes in an
event. So for example if I have an event that is represented as the XML
document below:


<BookFlight>
<Source>Expedia.com</Source>
<Date i18n="en">20.10.2009</Date>
<FlightNumber>OS362<FlightNumber>
</BookFlight>

If I had to later write query statements to retrieve information from
such an event I would write something like:


SELECT count(*) FROM BookFlight;
SELECT Source, Date.i18n FROM BookFlight;

The first statement for example would select every BookFlight event and
return the count of BookFlight events, whereas the second would return
information about the source and the date format.

The XSD for this event format is:


<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="BookFlight">
<xs:complexType>
<xs:sequence>
<xs:element name="Source" type="xs:string"/>
<xs:element ref="Date" />
<xs:element name="FlightNumber" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>


<xs:element name="Date">
<xs:complexType>
<xs:attribute name="i18n" type="xs:string" use="required" />
</xs:complexType>
</xs:element>
</xs:schema>

With such a schema saved to a file say BookFlight.xsd, you are able to
refer to this file within the esper configuration such that the engine
can validate the query statements to determine whether they conform to
the schema.

With these issues in mind, I had a schema which had one slight
difference to that shown above. Instead of having an element Source (on
the sixth line in the schema above), I had an attribute as below.


<xs:element name="BookFlight">
<xs:complexType>
<xs:sequence>
<xs:element ref="Date" />
<xs:element name="FlightNumber" type="xs:string"/>
</xs:sequence>
<xs:attribute name="Source" type="xs:string"/>
</xs:complexType>
</xs:element>

An instantiation of this schema would be:


<BookFlight Source="Expedia.com">
<Date i18n="en">20.10.2009</Date>
<FlightNumber>OS362<FlightNumber>
</BookFlight>

The problem with this is that I am not able to directly write queries like:


SELECT Source FROM BookFlight;

And so as far as I can tell at the moment, it is only possible to query
elements that are nested within the root node but not attributes of the
root node, and that limits the format of the XML schema that I can use.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



Re: Restrictions in XML Representations...?

by Thomas Bernhardt :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Some parts of this message have been removed. Learn more about Nabble's security policy.
Hi Emmanuel,

it may be best if you look at the Autoid example or the regression tests (i.e. com.espertech.esper.regression.event.TestSchemaXMLEvent) which query attributes.

Best regards
Tom

From: Emmanuel Mulo <e.mulo@...>
To: user@...
Sent: Wed, November 4, 2009 9:07:52 AM
Subject: [esper-user] Restrictions in XML Representations...?

Dear All,

While attempting to use XML event representations for the Esper event processing engine, I run into an issue that I decided to post about incase somebody else has the same.

Esper has the possibility to represent events as XML documents and performs the processing on the various elements and attributes in an event. So for example if I have an event that is represented as the XML document below:


<BookFlight>
<Source>Expedia.com</Source>
<Date i18n="en">20.10.2009</Date>
<FlightNumber>OS362<FlightNumber>
</BookFlight>

If I had to later write query statements to retrieve information from such an event I would write something like:


SELECT count(*) FROM BookFlight;
SELECT Source, Date.i18n FROM BookFlight;

The first statement for example would select every BookFlight event and return the count of BookFlight events, whereas the second would return information about the source and the date format.

The XSD for this event format is:


<?xml version="1.0" encoding="UTF-8"?>

<xs:element name="BookFlight">
<xs:complexType>
<xs:sequence>
<xs:element name="Source" type="xs:string"/>
<xs:element ref="Date" />
<xs:element name="FlightNumber" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>


<xs:element name="Date">
<xs:complexType>
<xs:attribute name="i18n" type="xs:string" use="required" />
</xs:complexType>
</xs:element>
</xs:schema>

With such a schema saved to a file say BookFlight.xsd, you are able to refer to this file within the esper configuration such that the engine can validate the query statements to determine whether they conform to the schema.

With these issues in mind, I had a schema which had one slight difference to that shown above. Instead of having an element Source (on the sixth line in the schema above), I had an attribute as below.


<xs:element name="BookFlight">
<xs:complexType>
<xs:sequence>
<xs:element ref="Date" />
<xs:element name="FlightNumber" type="xs:string"/>
</xs:sequence>
<xs:attribute name="Source" type="xs:string"/>
</xs:complexType>
</xs:element>

An instantiation of this schema would be:


<BookFlight Source="Expedia.com">
<Date i18n="en">20.10.2009</Date>
<FlightNumber>OS362<FlightNumber>
</BookFlight>

The problem with this is that I am not able to directly write queries like:


SELECT Source FROM BookFlight;

And so as far as I can tell at the moment, it is only possible to query elements that are nested within the root node but not attributes of the root node, and that limits the format of the XML schema that I can use.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

  http://xircles.codehaus.org/manage_email