[Property Tree] special character in XML tag
Hi, I have the following property tree, dumped in INFO format: CudbAppServiceId=1 { userLabel "" sqlAppSrvPlSchema identities-pl.sql CudbAppServiceId CudbAppServiceId=1 } When I dump it in XML format, I got the following: <?xml version="1.0" encoding="utf-8"?> <CudbAppServiceId=1> <userLabel/> <sqlAppSrvPlSchema>identities-pl.sql</sqlAppSrvPlSchema> <CudbAppServiceId>CudbAppServiceId=1</CudbAppServiceId> </CudbAppServiceId=1> This is not a valid XML, because we have a tag "CudbAppServiceId=1". Of course, any other xml parser like xmllint will fail to parse it, because of the equality sign in the tag. Is there any solution to this problem? Like somehow emitting = instead of the raw '=' inside the tag and in the text? Thanks, Gabor
On 02/18/2013 02:10 PM, Gábor Márton wrote:
Hi,
I have the following property tree, dumped in INFO format:
CudbAppServiceId=1 { userLabel "" sqlAppSrvPlSchema identities-pl.sql CudbAppServiceId CudbAppServiceId=1 }
When I dump it in XML format, I got the following:
<?xml version="1.0" encoding="utf-8"?> <CudbAppServiceId=1> <userLabel/> <sqlAppSrvPlSchema>identities-pl.sql</sqlAppSrvPlSchema> <CudbAppServiceId>CudbAppServiceId=1</CudbAppServiceId> </CudbAppServiceId=1>
This is not a valid XML, because we have a tag "CudbAppServiceId=1". Of course, any other xml parser like xmllint will fail to parse it, because of the equality sign in the tag.
Is there any solution to this problem? Like somehow emitting = instead of the raw '=' inside the tag and in the text?
Please file a bug. It might still be a few weeks before I get to work on PropertyTree properly again, and this mail will get lost otherwise. Sebastian
Will assume that he's filed a bug. Not sure what the intended goal is since I'm not familiar with INFO per se. Are we saying that CdbAppServiceId=1 is an attribute? Or is intended as a tab with "1" value? What sort of general bug is this? Does it impact pure Xml usage with Xml paths, parents, children, elements, attributes, values, etc? Thank you... On Mon, Feb 18, 2013 at 7:37 AM, Sebastian Redl < sebastian.redl@getdesigned.at> wrote:
On 02/18/2013 02:10 PM, Gábor Márton wrote:
Hi,
I have the following property tree, dumped in INFO format:
CudbAppServiceId=1 { userLabel "" sqlAppSrvPlSchema identities-pl.sql CudbAppServiceId CudbAppServiceId=1 }
When I dump it in XML format, I got the following:
<?xml version="1.0" encoding="utf-8"?> <CudbAppServiceId=1> <userLabel/> <sqlAppSrvPlSchema>identities-**pl.sql</sqlAppSrvPlSchema> <CudbAppServiceId>**CudbAppServiceId=1</**CudbAppServiceId> </CudbAppServiceId=1>
This is not a valid XML, because we have a tag "CudbAppServiceId=1". Of course, any other xml parser like xmllint will fail to parse it, because of the equality sign in the tag.
Is there any solution to this problem? Like somehow emitting = instead of the raw '=' inside the tag and in the text?
Please file a bug. It might still be a few weeks before I get to work on PropertyTree properly again, and this mail will get lost otherwise.
Sebastian
______________________________**_________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/**mailman/listinfo.cgi/boost-**users<http://lists.boost.org/mailman/listinfo.cgi/boost-users>
Hi, 'CudbAppServiceId=1' is not an attribute, this should be the tag itself. In fact, the XML would be correct if the tag would not contain the special equality sign. 'CudbAppServiceId=1' is a node in the property tree, which don't have value, but has 3 children. So a well formed XML would look like this, I suppose: <?xml version="1.0" encoding="utf-8"?> <CudbAppServiceId=1> <userLabel/> <sqlAppSrvPlSchema>identities-pl.sql</sqlAppSrvPlSchema> <CudbAppServiceId>CudbAppServiceId=1</CudbAppServiceId> </CudbAppServiceId=1> The bug is reported here: https://svn.boost.org/trac/boost/ticket/8095 BR, Gabor On Mon, Feb 18, 2013 at 4:38 PM, Michael Powell <mwpowellhtx@gmail.com> wrote:
Will assume that he's filed a bug. Not sure what the intended goal is since I'm not familiar with INFO per se. Are we saying that CdbAppServiceId=1 is an attribute?
Or is intended as a tab with "1" value? What sort of general bug is this? Does it impact pure Xml usage with Xml paths, parents, children, elements, attributes, values, etc?
Thank you...
On Mon, Feb 18, 2013 at 7:37 AM, Sebastian Redl <sebastian.redl@getdesigned.at> wrote:
On 02/18/2013 02:10 PM, Gábor Márton wrote:
Hi,
I have the following property tree, dumped in INFO format:
CudbAppServiceId=1 { userLabel "" sqlAppSrvPlSchema identities-pl.sql CudbAppServiceId CudbAppServiceId=1 }
When I dump it in XML format, I got the following:
<?xml version="1.0" encoding="utf-8"?> <CudbAppServiceId=1> <userLabel/> <sqlAppSrvPlSchema>identities-pl.sql</sqlAppSrvPlSchema> <CudbAppServiceId>CudbAppServiceId=1</CudbAppServiceId> </CudbAppServiceId=1>
This is not a valid XML, because we have a tag "CudbAppServiceId=1". Of course, any other xml parser like xmllint will fail to parse it, because of the equality sign in the tag.
Is there any solution to this problem? Like somehow emitting = instead of the raw '=' inside the tag and in the text?
Please file a bug. It might still be a few weeks before I get to work on PropertyTree properly again, and this mail will get lost otherwise.
Sebastian
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On Tue, Feb 19, 2013 at 3:30 AM, Gábor Márton <martongabesz@gmail.com>wrote:
Hi,
'CudbAppServiceId=1' is not an attribute, this should be the tag itself. In fact, the XML would be correct if the tag would not contain the special equality sign.
Kind of my point: I might challenge whether CubdAppServiceId1 wasn't intended to be the tag. The '=' just confuses things, except possibly as an artifact of the INFO specification, which I am ignorant of.
'CudbAppServiceId=1' is a node in the property tree, which don't have value, but has 3 children. So a well formed XML would look like this, I suppose: <?xml version="1.0" encoding="utf-8"?> <CudbAppServiceId=1> <userLabel/> <sqlAppSrvPlSchema>identities-pl.sql</sqlAppSrvPlSchema> <CudbAppServiceId>CudbAppServiceId=1</CudbAppServiceId> </CudbAppServiceId=1>
The bug is reported here: https://svn.boost.org/trac/boost/ticket/8095
BR, Gabor
On Mon, Feb 18, 2013 at 4:38 PM, Michael Powell <mwpowellhtx@gmail.com> wrote:
Will assume that he's filed a bug. Not sure what the intended goal is since I'm not familiar with INFO per se. Are we saying that CdbAppServiceId=1 is an attribute?
Or is intended as a tab with "1" value? What sort of general bug is this? Does it impact pure Xml usage with Xml paths, parents, children, elements, attributes, values, etc?
Thank you...
On Mon, Feb 18, 2013 at 7:37 AM, Sebastian Redl <sebastian.redl@getdesigned.at> wrote:
On 02/18/2013 02:10 PM, Gábor Márton wrote:
Hi,
I have the following property tree, dumped in INFO format:
CudbAppServiceId=1 { userLabel "" sqlAppSrvPlSchema identities-pl.sql CudbAppServiceId CudbAppServiceId=1 }
When I dump it in XML format, I got the following:
<?xml version="1.0" encoding="utf-8"?> <CudbAppServiceId=1> <userLabel/> <sqlAppSrvPlSchema>identities-pl.sql</sqlAppSrvPlSchema> <CudbAppServiceId>CudbAppServiceId=1</CudbAppServiceId> </CudbAppServiceId=1>
This is not a valid XML, because we have a tag "CudbAppServiceId=1". Of course, any other xml parser like xmllint will fail to parse it, because of the equality sign in the tag.
Is there any solution to this problem? Like somehow emitting = instead of the raw '=' inside the tag and in the text?
Please file a bug. It might still be a few weeks before I get to work on PropertyTree properly again, and this mail will get lost otherwise.
Sebastian
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Hi Michael, We are reading system wise configuration settings with the use of a special API, and then we are populating these values to the ptree. There are nodes in the system which has the signature described with this regex 'CudbAppServiceId=\d+'. Ptree itself handles this perfectly, so we gained a higher level abstraction via the proerty tree. The only problem is there, when we want to export the configuration to XML. Of course one solution would be to go through the ptree instance, and search for the regex mentioned before and replace the equality sign in every node. I consider this as a too high level solution, I think this should rather be handled in the write_xml function. BR, Gabor On Tue, Feb 19, 2013 at 12:34 PM, Michael Powell <mwpowellhtx@gmail.com> wrote:
On Tue, Feb 19, 2013 at 3:30 AM, Gábor Márton <martongabesz@gmail.com> wrote:
Hi,
'CudbAppServiceId=1' is not an attribute, this should be the tag itself. In fact, the XML would be correct if the tag would not contain the special equality sign.
Kind of my point: I might challenge whether CubdAppServiceId1 wasn't intended to be the tag. The '=' just confuses things, except possibly as an artifact of the INFO specification, which I am ignorant of.
'CudbAppServiceId=1' is a node in the property tree, which don't have value, but has 3 children. So a well formed XML would look like this, I suppose: <?xml version="1.0" encoding="utf-8"?> <CudbAppServiceId=1> <userLabel/> <sqlAppSrvPlSchema>identities-pl.sql</sqlAppSrvPlSchema> <CudbAppServiceId>CudbAppServiceId=1</CudbAppServiceId> </CudbAppServiceId=1>
The bug is reported here: https://svn.boost.org/trac/boost/ticket/8095
BR, Gabor
On Mon, Feb 18, 2013 at 4:38 PM, Michael Powell <mwpowellhtx@gmail.com> wrote:
Will assume that he's filed a bug. Not sure what the intended goal is since I'm not familiar with INFO per se. Are we saying that CdbAppServiceId=1 is an attribute?
Or is intended as a tab with "1" value? What sort of general bug is this? Does it impact pure Xml usage with Xml paths, parents, children, elements, attributes, values, etc?
Thank you...
On Mon, Feb 18, 2013 at 7:37 AM, Sebastian Redl <sebastian.redl@getdesigned.at> wrote:
On 02/18/2013 02:10 PM, Gábor Márton wrote:
Hi,
I have the following property tree, dumped in INFO format:
CudbAppServiceId=1 { userLabel "" sqlAppSrvPlSchema identities-pl.sql CudbAppServiceId CudbAppServiceId=1 }
When I dump it in XML format, I got the following:
<?xml version="1.0" encoding="utf-8"?> <CudbAppServiceId=1> <userLabel/> <sqlAppSrvPlSchema>identities-pl.sql</sqlAppSrvPlSchema> <CudbAppServiceId>CudbAppServiceId=1</CudbAppServiceId> </CudbAppServiceId=1>
This is not a valid XML, because we have a tag "CudbAppServiceId=1". Of course, any other xml parser like xmllint will fail to parse it, because of the equality sign in the tag.
Is there any solution to this problem? Like somehow emitting = instead of the raw '=' inside the tag and in the text?
Please file a bug. It might still be a few weeks before I get to work on PropertyTree properly again, and this mail will get lost otherwise.
Sebastian
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
On Tue, Feb 19, 2013 at 7:57 AM, Gábor Márton <martongabesz@gmail.com>wrote:
Hi Michael,
We are reading system wise configuration settings with the use of a special API, and then we are populating these values to the ptree. There are nodes in the system which has the signature described with this regex 'CudbAppServiceId=\d+'. Ptree itself handles this perfectly, so we gained a higher level abstraction via the proerty tree. The only problem is there, when we want to export the configuration to XML.
Yessir, I see. Well, I've worked with Xml for a number of years and I don't think I've ever seen a case like that. Given your use case, it would be more typical to do something like this: <CudbAppServiceId value="\d+" /> (excuse the mixed Xml / regex); or <CudbAppServiceId value="\d+">...</CudbAppServiceId> (parent element, with whatever children). Or could even do something like this: <CudbAppServiceId>1</CudbAppServiceId>, but it sounds like there are children elements involved, so likely not. That's my two cents anyway. Good hunting!
Of course one solution would be to go through the ptree instance, and search for the regex mentioned before and replace the equality sign in every node. I consider this as a too high level solution, I think this should rather be handled in the write_xml function.
BR, Gabor
On Tue, Feb 19, 2013 at 12:34 PM, Michael Powell <mwpowellhtx@gmail.com> wrote:
On Tue, Feb 19, 2013 at 3:30 AM, Gábor Márton <martongabesz@gmail.com> wrote:
Hi,
'CudbAppServiceId=1' is not an attribute, this should be the tag itself. In fact, the XML would be correct if the tag would not contain the special equality sign.
Kind of my point: I might challenge whether CubdAppServiceId1 wasn't intended to be the tag. The '=' just confuses things, except possibly as
an
artifact of the INFO specification, which I am ignorant of.
'CudbAppServiceId=1' is a node in the property tree, which don't have value, but has 3 children. So a well formed XML would look like this, I suppose: <?xml version="1.0" encoding="utf-8"?> <CudbAppServiceId=1> <userLabel/> <sqlAppSrvPlSchema>identities-pl.sql</sqlAppSrvPlSchema> <CudbAppServiceId>CudbAppServiceId=1</CudbAppServiceId> </CudbAppServiceId=1>
The bug is reported here: https://svn.boost.org/trac/boost/ticket/8095
BR, Gabor
On Mon, Feb 18, 2013 at 4:38 PM, Michael Powell <mwpowellhtx@gmail.com> wrote:
Will assume that he's filed a bug. Not sure what the intended goal is since I'm not familiar with INFO per se. Are we saying that
CdbAppServiceId=1
is an attribute?
Or is intended as a tab with "1" value? What sort of general bug is this? Does it impact pure Xml usage with Xml paths, parents, children, elements, attributes, values, etc?
Thank you...
On Mon, Feb 18, 2013 at 7:37 AM, Sebastian Redl <sebastian.redl@getdesigned.at> wrote:
On 02/18/2013 02:10 PM, Gábor Márton wrote:
Hi,
I have the following property tree, dumped in INFO format:
CudbAppServiceId=1 { userLabel "" sqlAppSrvPlSchema identities-pl.sql CudbAppServiceId CudbAppServiceId=1 }
When I dump it in XML format, I got the following:
<?xml version="1.0" encoding="utf-8"?> <CudbAppServiceId=1> <userLabel/> <sqlAppSrvPlSchema>identities-pl.sql</sqlAppSrvPlSchema> <CudbAppServiceId>CudbAppServiceId=1</CudbAppServiceId> </CudbAppServiceId=1>
This is not a valid XML, because we have a tag "CudbAppServiceId=1". Of course, any other xml parser like xmllint will fail to parse it, because of the equality sign in the tag.
Is there any solution to this problem? Like somehow emitting = instead of the raw '=' inside the tag and in the text?
Please file a bug. It might still be a few weeks before I get to work on PropertyTree properly again, and this mail will get lost otherwise.
Sebastian
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Oh, and here's an Xml serialization tip: you probably already know this if you've dealt with serialization issues before. Not sure how it is with INFO, but with Xml, be prepared for asymmetric reads. Writes are pretty much a straight shot, but reads can be asymmetric: meaning you are not guaranteed to find attributes, elements, etc in any particular order, as a general rule, at least not without some help, sorting capability, etc. Good hunting! On Tue, Feb 19, 2013 at 7:57 AM, Gábor Márton <martongabesz@gmail.com>wrote:
Hi Michael,
We are reading system wise configuration settings with the use of a special API, and then we are populating these values to the ptree. There are nodes in the system which has the signature described with this regex 'CudbAppServiceId=\d+'. Ptree itself handles this perfectly, so we gained a higher level abstraction via the proerty tree. The only problem is there, when we want to export the configuration to XML. Of course one solution would be to go through the ptree instance, and search for the regex mentioned before and replace the equality sign in every node. I consider this as a too high level solution, I think this should rather be handled in the write_xml function.
BR, Gabor
On Tue, Feb 19, 2013 at 12:34 PM, Michael Powell <mwpowellhtx@gmail.com> wrote:
On Tue, Feb 19, 2013 at 3:30 AM, Gábor Márton <martongabesz@gmail.com> wrote:
Hi,
'CudbAppServiceId=1' is not an attribute, this should be the tag itself. In fact, the XML would be correct if the tag would not contain the special equality sign.
Kind of my point: I might challenge whether CubdAppServiceId1 wasn't intended to be the tag. The '=' just confuses things, except possibly as
an
artifact of the INFO specification, which I am ignorant of.
'CudbAppServiceId=1' is a node in the property tree, which don't have value, but has 3 children. So a well formed XML would look like this, I suppose: <?xml version="1.0" encoding="utf-8"?> <CudbAppServiceId=1> <userLabel/> <sqlAppSrvPlSchema>identities-pl.sql</sqlAppSrvPlSchema> <CudbAppServiceId>CudbAppServiceId=1</CudbAppServiceId> </CudbAppServiceId=1>
The bug is reported here: https://svn.boost.org/trac/boost/ticket/8095
BR, Gabor
On Mon, Feb 18, 2013 at 4:38 PM, Michael Powell <mwpowellhtx@gmail.com> wrote:
Will assume that he's filed a bug. Not sure what the intended goal is since I'm not familiar with INFO per se. Are we saying that
CdbAppServiceId=1
is an attribute?
Or is intended as a tab with "1" value? What sort of general bug is this? Does it impact pure Xml usage with Xml paths, parents, children, elements, attributes, values, etc?
Thank you...
On Mon, Feb 18, 2013 at 7:37 AM, Sebastian Redl <sebastian.redl@getdesigned.at> wrote:
On 02/18/2013 02:10 PM, Gábor Márton wrote:
Hi,
I have the following property tree, dumped in INFO format:
CudbAppServiceId=1 { userLabel "" sqlAppSrvPlSchema identities-pl.sql CudbAppServiceId CudbAppServiceId=1 }
When I dump it in XML format, I got the following:
<?xml version="1.0" encoding="utf-8"?> <CudbAppServiceId=1> <userLabel/> <sqlAppSrvPlSchema>identities-pl.sql</sqlAppSrvPlSchema> <CudbAppServiceId>CudbAppServiceId=1</CudbAppServiceId> </CudbAppServiceId=1>
This is not a valid XML, because we have a tag "CudbAppServiceId=1". Of course, any other xml parser like xmllint will fail to parse it, because of the equality sign in the tag.
Is there any solution to this problem? Like somehow emitting = instead of the raw '=' inside the tag and in the text?
Please file a bug. It might still be a few weeks before I get to work on PropertyTree properly again, and this mail will get lost otherwise.
Sebastian
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
participants (3)
-
Gábor Márton -
Michael Powell -
Sebastian Redl