From boris at codesynthesis.com Fri Nov 11 05:33:34 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Nov 11 05:36:50 2011 Subject: [xsde-users] Re: [xsd-users] error processing multiple schemas at once In-Reply-To: References: <9DFD5D06-5029-44ED-B35C-61725F226E90@csr.com> Message-ID: Hi Eric, In the future, please send questions about XSD/e to the xsde-users mailing list instead of xsd-users. Eric Broadbent writes: > when I built XSDE, many serialization files were built - whether or not > I set "XSDE_SERIALIZER_VALIDATION" on or off in config..make > > (Here's a partial listing of the compiles with > XSDE_SERIALIZER_VALIDATION := n") > > g++ -I.. -W -Wall -O3 -c cxx/serializer/elements.cxx -o cxx/serializer/elements.o > g++ -I.. -W -Wall -O3 -c cxx/serializer/context.cxx -o cxx/serializer/context.o > g++ -I.. -W -Wall -O3 -c cxx/serializer/genx/document.cxx -o cxx/serializer/genx/document.o > g++ -I.. -W -Wall -O3 -c cxx/serializer/genx/xml-error.cxx -o cxx/serializer/genx/xml-error.o > g++ -I.. -W -Wall -O3 -c cxx/serializer/exceptions.cxx -o cxx/serializer/exceptions.o > g++ -I.. -W -Wall -O3 -c cxx/serializer/non-validating/serializer.cxx -o cxx/serializer/non-validating/serializer.o > g++ -I.. -W -Wall -O3 -c cxx/serializer/non-validating/time-zone.cxx -o cxx/serializer/non-validating/time-zone.o > g++ -I.. -W -Wall -O3 -c cxx/serializer/non-validating/xml-schema-sskel.cxx -o cxx/serializer/non-validating/xml-schema-sskel.o > <... 40 lines skipped ...> > g++ -I.. -W -Wall -O3 -c cxx/serializer/non-validating/date-time.cxx -o cxx/serializer/non-validating/date-time.o > g++ -I.. -W -Wall -O3 -c cxx/serializer/non-validating/duration.cxx -o cxx/serializer/non-validating/duration.o > > I was operating with the understanding that serialization is optional - but > perhaps that's only when schema-compilation is run (after XSDE is built). > The chapter on Serialization > (http://www.codesynthesis.com/projects/xsd/documentation/cxx/tree/manual/#4) > indicates: > > "Note that the generation of the serialization code is optional and should > be explicitly requested with the --generate-serialization option." XSDE_SERIALIZER_VALIDATION only controls whether serialization will be built with validation support or without. But the runtime will always include the serialization support. However, if you don't compile any of your schemas with serialization support, then none of the symbols from the runtime (which is a static library) will end up in the resulting executable. > Secondly, in the software that XSDE will be linked into, Expat exists > already. Instead of having the XSDE build process compile another > instance of Expat, is it possible for me to just point the XSDE > library at the existing build? (Assuming they are the same release > of Expat which they are) There is no way to disable Expat compilation in the XSD/e runtime other than manually removing the files from the makefile (see libxsde/xsde/makefile; there is just one line to comment). Boris From Eric.Broadbent at csr.com Mon Nov 21 23:18:23 2011 From: Eric.Broadbent at csr.com (Eric Broadbent) Date: Mon Nov 21 23:18:29 2011 Subject: [xsde-users] v_state_, v_state_stack_, etc. Message-ID: <48F083B2-98E5-4644-AD6B-C4FE47A54E60@csr.com> I am looking through the generated files in the example library parser, under examples/cxx/parser/generated library-pimpl.cxx library-pimpl.hxx library-pskel.cxx library-pskel.hxx library-pskel.ixx In the pskel files, I see a number of constructs and references to "v_state" and variations of that name: struct v_state_descr_ struct v_state_ ::xsde::cxx::stack v_state_stack_; These are not mentioned in the documentation - I wasn't able to find the string "v_state" in Embedded C++/Hybrid Mapping Getting Started Guide Embedded C++/Parser Mapping Getting Started Guide Embedded C++/Serializer Mapping Getting Started Guide Presumably it's because this is stuff that we don't need to monkey with at all - and guessing from the name it may have to do with validation. Is there a reason to be aware of these v_state entities? Thanks, -Eric B. Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog From boris at codesynthesis.com Tue Nov 22 04:42:38 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Nov 22 04:48:32 2011 Subject: [xsde-users] v_state_, v_state_stack_, etc. In-Reply-To: <48F083B2-98E5-4644-AD6B-C4FE47A54E60@csr.com> References: <48F083B2-98E5-4644-AD6B-C4FE47A54E60@csr.com> Message-ID: Hi Eric, Eric Broadbent writes: > In the pskel files, I see a number of constructs and references to "v_state" > and variations of that name: > > struct v_state_descr_ > struct v_state_ > > ::xsde::cxx::stack v_state_stack_; > > Presumably it's because this is stuff that we don't need to monkey > with at all - and guessing from the name it may have to do with > validation. Yes, these are implementation details (XML Schema validation state). Boris From Eric.Broadbent at csr.com Tue Nov 29 00:29:17 2011 From: Eric.Broadbent at csr.com (Eric Broadbent) Date: Tue Nov 29 00:29:26 2011 Subject: [xsde-users] ignoring parts of the schema - and referenced schemas Message-ID: <54B9B91B-084A-4AB4-ADA6-3CC854D486E8@csr.com> Hi and many thanks for a very nice solution, I have found the generated code to be very efficient. The schema that I need to work with contains elements which are defined in other schemas, so I have generated the various parser skeleton/implementation parsers individually and then linked them all together with the main schema driver (I'm testing the generated printf driver version). The root element contains many elements, only two of which I'm really interested in parsing and building objects for, so I provided type-maps only for these two sub-elements. I've also followed the directions on page 20 of the "Embedded C++/Parser Mapping Getting Started Guide" to skip over elements that I don't care about: "You might be wondering what happens if you do not provide a parser by not calling one of the *_parser() functions. In that case the corresponding XML content will be skipped, including validation. This is an efficient way to ignore parts of the document that you are not interested in. An alternative, shorter, way to connect the parsers is by using the parsers() functions which connects all the parsers for a given type at once:" First I tried this by passing NULL to the bundle-form of the _parsers() connection function, but I got compiler errors - so I had to use the one-by-one "*_parser()" functions, calling only the ones associated with the elements that I am interested in. When I run the driver on sample XML docs, I get errors like this: ... test2.xml:2:381: unexpected attribute encountered When I try to debug the code, I wasn't able to figure out where to break in an element handler to tell what element it's encountered, although I can find the element that is causing the problem via the error message "line:pos" notation. The problem seems to be that I have not generated parsing code for all the possible schemas that can be referenced via attributes. It seems that there can be "optional" elements, which essentially allow namespaces to be extended. This looks something like this - appearing in any given element attribute list: xmlns:foo="http://schemas.foo.org/2011/XMLSchema-foo" xmlns:bar="http://schemas.foo.org/2011/XMLSchema-bar" foo:foobar=bar where "foobar" is an attribute in the schema XMLSchema-foo, and "bar" is yet another namespace represented by another schema. The use of the "foobar" attribute to give meaning to the "bar" namespace is dependent on the ability to interpret the semantics of the "foo" schema. As far as my application is concerned, I do not need to do anything with these attributes or namespaces, and I would like the parser to ignore them. However, since this kind of namespace reference is dynamic, perhaps there is no opportunity to tell the parser to skip over these attributes - in the same way that we can tell it to skip over elements. Therefore I am not sure how to deal with this situation - except to have pre-processed any possible "optional" schema beforehand and built parsers for it. My question is - is there any way to skip over unknown element attributes like this that are referring to other schemas that I have no handlers for (and no need for)? Thanks again for the powerful software and the assistance using it. -Eric B. Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog From boris at codesynthesis.com Tue Nov 29 10:17:53 2011 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Nov 29 10:25:27 2011 Subject: [xsde-users] ignoring parts of the schema - and referenced schemas In-Reply-To: <54B9B91B-084A-4AB4-ADA6-3CC854D486E8@csr.com> References: <54B9B91B-084A-4AB4-ADA6-3CC854D486E8@csr.com> Message-ID: Hi Eric, Eric Broadbent writes: > The problem seems to be that I have not generated parsing code for all the > possible schemas that can be referenced via attributes. > It seems that there can be "optional" elements, which essentially allow > namespaces to be extended. > > This looks something like this - appearing in any given element attribute > list: > > xmlns:foo="http://schemas.foo.org/2011/XMLSchema-foo" > xmlns:bar="http://schemas.foo.org/2011/XMLSchema-bar" > foo:foobar=bar > > where "foobar" is an attribute in the schema XMLSchema-foo, and "bar" is yet > another namespace represented by another schema. The use of the "foobar" > attribute to give meaning to the "bar" namespace is dependent on the ability > to interpret the semantics of the "foo" schema. > > As far as my application is concerned, I do not need to do anything with > these attributes or namespaces, and I would like the parser to ignore them. > However, since this kind of namespace reference is dynamic, perhaps there is > no opportunity to tell the parser to skip over these attributes - in the > same way that we can tell it to skip over elements. Therefore I am not sure > how to deal with this situation - except to have pre-processed any possible > "optional" schema beforehand and built parsers for it. > > My question is - is there any way to skip over unknown element attributes > like this that are referring to other schemas that I have no handlers for > (and no need for)? I am having a hard time understanding how the "extension schemas" are working in your setup without seeing some concrete examples. Generally, though, you can skip any valid element or attribute by simply not providing a parser for it. By valid I mean that it is valid for such an element/attribute to appear in the content, per the schema. Normally, schema extensions are arranged using the xsd:any or xsd:anyAttribute wildcards. By default their content will be ignored but the namespaces of the elements/attributes will still be checked. The only way to ignore an invalid element or attribute (i.e., one that is not allowed by the schema) is to disable validation. Boris From Eric.Broadbent at csr.com Tue Nov 29 23:02:20 2011 From: Eric.Broadbent at csr.com (Eric Broadbent) Date: Tue Nov 29 23:02:29 2011 Subject: [xsde-users] ignoring parts of the schema - and referenced schemas In-Reply-To: References: <54B9B91B-084A-4AB4-ADA6-3CC854D486E8@csr.com> Message-ID: <043B89C2-FDBE-4B34-B879-B38FCC210705@csr.com> Hi Boris, thanks for the reply - sorry my previous query was vague. I found an example of this kind of namespace reference in Office documents. Here is the root document element from a random Word docx file on my computer: According to specs I am able to see, the "document" element does not have any attributes. http://www.schemacentral.com/sc/ooxml/e-w_document.html The document tag contains references to other schemas necessary to specify child elements, and then there are two attributes in the "ve" namespace: ve:Ignorable ve:PreserveAttributes In order to be able to parse these attributes, the parser must know about the "markup-compatibility" schema, however the child elements do not use this schema - it's only necessary to interpret these extra attributes. So unless one processes the "markup-compatibility" schema with XSD and generates parsers for it - these attributes will be "unexpected" and declared invalid. Is this the only way around these kind of "extension" attributes? Thanks for your help, -Eric On Nov 29, 2011, at 10:17 AM, Boris Kolpackov wrote: > Hi Eric, > > Eric Broadbent writes: > >> The problem seems to be that I have not generated parsing code for all the >> possible schemas that can be referenced via attributes. >> It seems that there can be "optional" elements, which essentially allow >> namespaces to be extended. >> >> This looks something like this - appearing in any given element attribute >> list: >> >> xmlns:foo="http://schemas.foo.org/2011/XMLSchema-foo" >> xmlns:bar="http://schemas.foo.org/2011/XMLSchema-bar" >> foo:foobar=bar >> >> where "foobar" is an attribute in the schema XMLSchema-foo, and "bar" is yet >> another namespace represented by another schema. The use of the "foobar" >> attribute to give meaning to the "bar" namespace is dependent on the ability >> to interpret the semantics of the "foo" schema. >> >> As far as my application is concerned, I do not need to do anything with >> these attributes or namespaces, and I would like the parser to ignore them. >> However, since this kind of namespace reference is dynamic, perhaps there is >> no opportunity to tell the parser to skip over these attributes - in the >> same way that we can tell it to skip over elements. Therefore I am not sure >> how to deal with this situation - except to have pre-processed any possible >> "optional" schema beforehand and built parsers for it. >> >> My question is - is there any way to skip over unknown element attributes >> like this that are referring to other schemas that I have no handlers for >> (and no need for)? > > I am having a hard time understanding how the "extension schemas" are > working in your setup without seeing some concrete examples. Generally, > though, you can skip any valid element or attribute by simply not > providing a parser for it. By valid I mean that it is valid for such > an element/attribute to appear in the content, per the schema. > > Normally, schema extensions are arranged using the xsd:any or > xsd:anyAttribute wildcards. By default their content will be ignored > but the namespaces of the elements/attributes will still be checked. > > The only way to ignore an invalid element or attribute (i.e., one > that is not allowed by the schema) is to disable validation. > > Boris > > > To report this email as spam click https://www.mailcontrol.com/sr/wQw0zmjPoHdJTZGyOCrrhg== . Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog From eric.broadbent at csr.com Wed Nov 30 15:39:43 2011 From: eric.broadbent at csr.com (Eric Broadbent) Date: Wed Nov 30 15:40:40 2011 Subject: [xsde-users] ignoring parts of the schema - and referenced schemas In-Reply-To: <043B89C2-FDBE-4B34-B879-B38FCC210705@csr.com> References: <54B9B91B-084A-4AB4-ADA6-3CC854D486E8@csr.com> <043B89C2-FDBE-4B34-B879-B38FCC210705@csr.com> Message-ID: <34C22A81-6459-41CE-A3B8-90AA6085662F@csr.com> Just an update - I tried the method of creating the parser skeleton/implementation code for this "extension" schema and building it into the application, in hopes that parser would recognize the attribute if an element's attributes were extended like this. However I still get "unexpected attribute encountered". So I'm going to try turning off validation next. On Nov 29, 2011, at 11:02 PM, Eric Broadbent wrote: > Hi Boris, > thanks for the reply - sorry my previous query was vague. > > I found an example of this kind of namespace reference in Office documents. > Here is the root document element from a random Word docx file on my computer: > > xmlns:ve="http://schemas.openxmlformats.org/markup-compatibility/2006" > xmlns:mv="urn:schemas-microsoft-com:mac:vml" > xmlns:o="urn:schemas-microsoft-com:office:office" > xmlns:r="http://schemas.openxmlformats.org/officeDocument/2006/relationships" > xmlns:m="http://schemas.openxmlformats.org/officeDocument/2006/math" > xmlns:v="urn:schemas-microsoft-com:vml" > xmlns:wp="http://schemas.openxmlformats.org/drawingml/2006/wordprocessingDrawing" > xmlns:w10="urn:schemas-microsoft-com:office:word" > xmlns:w="http://schemas.openxmlformats.org/wordprocessingml/2006/main" > xmlns:wne="http://schemas.microsoft.com/office/word/2006/wordml" > ve:Ignorable="mv" > ve:PreserveAttributes="mv:*"> > > According to specs I am able to see, the "document" element does not have any attributes. > > http://www.schemacentral.com/sc/ooxml/e-w_document.html > > The document tag contains references to other schemas necessary to specify child elements, and then there are two attributes in the "ve" namespace: > > ve:Ignorable > ve:PreserveAttributes > > In order to be able to parse these attributes, the parser must know about the "markup-compatibility" schema, however the child elements do not use this schema - it's only necessary to interpret these extra attributes. > > So unless one processes the "markup-compatibility" schema with XSD and generates parsers for it - these attributes will be "unexpected" and declared invalid. > Is this the only way around these kind of "extension" attributes? > > Thanks for your help, > > -Eric > > On Nov 29, 2011, at 10:17 AM, Boris Kolpackov wrote: > >> Hi Eric, >> >> Eric Broadbent writes: >> >>> The problem seems to be that I have not generated parsing code for all the >>> possible schemas that can be referenced via attributes. >>> It seems that there can be "optional" elements, which essentially allow >>> namespaces to be extended. >>> >>> This looks something like this - appearing in any given element attribute >>> list: >>> >>> xmlns:foo="http://schemas.foo.org/2011/XMLSchema-foo" >>> xmlns:bar="http://schemas.foo.org/2011/XMLSchema-bar" >>> foo:foobar=bar >>> >>> where "foobar" is an attribute in the schema XMLSchema-foo, and "bar" is yet >>> another namespace represented by another schema. The use of the "foobar" >>> attribute to give meaning to the "bar" namespace is dependent on the ability >>> to interpret the semantics of the "foo" schema. >>> >>> As far as my application is concerned, I do not need to do anything with >>> these attributes or namespaces, and I would like the parser to ignore them. >>> However, since this kind of namespace reference is dynamic, perhaps there is >>> no opportunity to tell the parser to skip over these attributes - in the >>> same way that we can tell it to skip over elements. Therefore I am not sure >>> how to deal with this situation - except to have pre-processed any possible >>> "optional" schema beforehand and built parsers for it. >>> >>> My question is - is there any way to skip over unknown element attributes >>> like this that are referring to other schemas that I have no handlers for >>> (and no need for)? >> >> I am having a hard time understanding how the "extension schemas" are >> working in your setup without seeing some concrete examples. Generally, >> though, you can skip any valid element or attribute by simply not >> providing a parser for it. By valid I mean that it is valid for such >> an element/attribute to appear in the content, per the schema. >> >> Normally, schema extensions are arranged using the xsd:any or >> xsd:anyAttribute wildcards. By default their content will be ignored >> but the namespaces of the elements/attributes will still be checked. >> >> The only way to ignore an invalid element or attribute (i.e., one >> that is not allowed by the schema) is to disable validation. >> >> Boris >> >> >> To report this email as spam click https://www.mailcontrol.com/sr/wQw0zmjPoHdJTZGyOCrrhg== . > > > > Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom > More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog > From eric.broadbent at csr.com Wed Nov 30 20:47:56 2011 From: eric.broadbent at csr.com (Eric Broadbent) Date: Wed Nov 30 20:48:06 2011 Subject: [xsde-users] Re: ignoring parts of the schema - and referenced schemas In-Reply-To: <34C22A81-6459-41CE-A3B8-90AA6085662F@csr.com> References: <54B9B91B-084A-4AB4-ADA6-3CC854D486E8@csr.com> <043B89C2-FDBE-4B34-B879-B38FCC210705@csr.com> <34C22A81-6459-41CE-A3B8-90AA6085662F@csr.com> Message-ID: <781FA5C8-84E5-41BC-A2F3-487B28CE58BA@csr.com> And finally, to close the topic: removing validation allows the unexpected attribute to pass without complaint. Thanks. -EricB On Nov 30, 2011, at 3:39 PM, Eric Broadbent wrote: > Just an update - I tried the method of creating the parser skeleton/implementation code for this "extension" schema and building it into the application, in hopes that parser would recognize the attribute if an element's attributes were extended like this. > However I still get "unexpected attribute encountered". > So I'm going to try turning off validation next. > > On Nov 29, 2011, at 11:02 PM, Eric Broadbent wrote: > >> Hi Boris, >> thanks for the reply - sorry my previous query was vague. >> >> I found an example of this kind of namespace reference in Office documents. >> Here is the root document element from a random Word docx file on my computer: >> >> > xmlns:ve="http://schemas.openxmlformats.org/markup-compatibility/2006" >> xmlns:mv="urn:schemas-microsoft-com:mac:vml" >> xmlns:o="urn:schemas-microsoft-com:office:office" >> xmlns:r="http://schemas.openxmlformats.org/officeDocument/2006/relationships" >> xmlns:m="http://schemas.openxmlformats.org/officeDocument/2006/math" >> xmlns:v="urn:schemas-microsoft-com:vml" >> xmlns:wp="http://schemas.openxmlformats.org/drawingml/2006/wordprocessingDrawing" >> xmlns:w10="urn:schemas-microsoft-com:office:word" >> xmlns:w="http://schemas.openxmlformats.org/wordprocessingml/2006/main" >> xmlns:wne="http://schemas.microsoft.com/office/word/2006/wordml" >> ve:Ignorable="mv" >> ve:PreserveAttributes="mv:*"> >> >> According to specs I am able to see, the "document" element does not have any attributes. >> >> http://www.schemacentral.com/sc/ooxml/e-w_document.html >> >> The document tag contains references to other schemas necessary to specify child elements, and then there are two attributes in the "ve" namespace: >> >> ve:Ignorable >> ve:PreserveAttributes >> >> In order to be able to parse these attributes, the parser must know about the "markup-compatibility" schema, however the child elements do not use this schema - it's only necessary to interpret these extra attributes. >> >> So unless one processes the "markup-compatibility" schema with XSD and generates parsers for it - these attributes will be "unexpected" and declared invalid. >> Is this the only way around these kind of "extension" attributes? >> >> Thanks for your help, >> >> -Eric >> >> On Nov 29, 2011, at 10:17 AM, Boris Kolpackov wrote: >> >>> Hi Eric, >>> >>> Eric Broadbent writes: >>> >>>> The problem seems to be that I have not generated parsing code for all the >>>> possible schemas that can be referenced via attributes. >>>> It seems that there can be "optional" elements, which essentially allow >>>> namespaces to be extended. >>>> >>>> This looks something like this - appearing in any given element attribute >>>> list: >>>> >>>> xmlns:foo="http://schemas.foo.org/2011/XMLSchema-foo" >>>> xmlns:bar="http://schemas.foo.org/2011/XMLSchema-bar" >>>> foo:foobar=bar >>>> >>>> where "foobar" is an attribute in the schema XMLSchema-foo, and "bar" is yet >>>> another namespace represented by another schema. The use of the "foobar" >>>> attribute to give meaning to the "bar" namespace is dependent on the ability >>>> to interpret the semantics of the "foo" schema. >>>> >>>> As far as my application is concerned, I do not need to do anything with >>>> these attributes or namespaces, and I would like the parser to ignore them. >>>> However, since this kind of namespace reference is dynamic, perhaps there is >>>> no opportunity to tell the parser to skip over these attributes - in the >>>> same way that we can tell it to skip over elements. Therefore I am not sure >>>> how to deal with this situation - except to have pre-processed any possible >>>> "optional" schema beforehand and built parsers for it. >>>> >>>> My question is - is there any way to skip over unknown element attributes >>>> like this that are referring to other schemas that I have no handlers for >>>> (and no need for)? >>> >>> I am having a hard time understanding how the "extension schemas" are >>> working in your setup without seeing some concrete examples. Generally, >>> though, you can skip any valid element or attribute by simply not >>> providing a parser for it. By valid I mean that it is valid for such >>> an element/attribute to appear in the content, per the schema. >>> >>> Normally, schema extensions are arranged using the xsd:any or >>> xsd:anyAttribute wildcards. By default their content will be ignored >>> but the namespaces of the elements/attributes will still be checked. >>> >>> The only way to ignore an invalid element or attribute (i.e., one >>> that is not allowed by the schema) is to disable validation. >>> >>> Boris >>> >>> >>> To report this email as spam click https://www.mailcontrol.com/sr/wQw0zmjPoHdJTZGyOCrrhg== . >> >> >> >> Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom >> More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog >> > >