Hello!
I'm trying to work with a webservice for geospatial data. Interfacing with it was easy, since it is WSDL. But the output format of most of the request is a rather convoluted mess of XML namespaces nested into each other, and I am not able to get a XML->Smalltalk-Binding working for it. The WSDL description is very badly formed, and describes the return type as "string", even though it is an XML document of a particular type, so I have to do this by hand. I do not have access to the DTDs of the various namespaces in questions, which further complicates matters. Maybe it's best if I start with an example: | <?xml version='1.0' encoding='ISO-8859-1'?> | <outer:outerContainer | xmlns:outer="urn:outerSchema" | xmlns:geo="urn:geoSchema"> | xmlns:data="urn:dataSchema"> | | <geo:someObject> | <geo:data>...</geo:data> | </geo:someObject> | | <geo:innerContainer> | <data:complexObjectA> | <data:data1>...</data:data1> | <data:data2>...</data:data2> | <data:data3>...</data:data3> | ... | <data:geometry> | <geo:polygon> | 123.45 67.890 | 333.22 22.888 | ... | </geo:polygon> | </data:geometry> | </data:complexObjectA> | </geo:innerContainer> | | <geo:innerContainer> | ... | </geo:innerContainer> | | ... | </outer:outerContainer> On the surface, it seems rather straightforward: I have an "outerContainer", which in turn contains some stuff, and in particular some "innerContainer"s, which _then_ contain the real data I'm interested in. If all of them were contained in the same namespace, I'd already have it done and working. However, I haven't got a clue how to define this weird kind of inter-namespace relations such that the XMLObjectMarshallingManager is then able to parse such a thing. Til now, I've created three bindings, one for each of the schemata, and I cross-reference the "alien" objects by explicitely including their corresponding namespaces: | <?xml version="1.0" encoding="utf-8" ?> | <schemaBindings> | <xmlToSmalltalkBinding name="" targetNamespace="urn:schemaOuter" xmlns:xsd="http://www.w3.org/2001/XMLSchema" | xmlns:outer="urn:outerSchema" xmlns:geo="urn:geoSchema"> | | <object name="outerContainer" smalltalkClass="OuterCollection"> | <element name="contents" ref="tns:CollectionOfOuterContainer" aspect="contents"/> | </object> | <sequence_of name="CollectionOfOuterContainer"> | <element name="contents" minOccurs="0" maxOccurs="unbounded" ref="geo:innerContainer"/> | </sequence_of> | </xmlToSmalltalkBinding> | </schemaBindings> Note especially the "xmlns:geo='urn:geoSchema'" to reference the second schema. This way the binding parses and is installed without errors (if the bindings are loaded in the correct order). However, if I now try to actually unmarshal something, the unmarshaller already chokes at the <outer:outerContainer> elements, since it cannot find any "contents"-Elements in it. I'm thoroughly stuck now -- I could in theory resort to do manual parsing with XML.Parser (and in fact, this is what I began with, before I discovered XMLObjectBinding), but it sure would be a nightmare to do it that way. Basically my question is whether I'm actually on the right track, and it is possible to construct a binding or whatever to parse such kind of data -- without having to do it "by hand" with the XML.Parser. Or any other hints of how to get this kind of data "into" Smalltalk with reasonable effort. (If the examples are not clear, I can provide "real" data as from the webservice -- since they are rather large I didn't want to make this posting any longer than it already is.) Many thanks in advance, Stefan _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Hi Stefan,
I am not quite sure whether I understand you right. Resembles the following structure approximately your target structure? (OuterContainter new) contents: ((OrderedCollection new) add: ComplexObject new; ... yourself) In fact I am developing a library to map messy XML to objects, since I've dealt too often with weird XMLs. The following binding could be a mapping for your XML. ----- namespace outer="urn:outerSchema" namespace outer="urn:geoSchema" namespace outer="urn:dataSchema" root element ROOT { class: OuterContainer, geo:innerContainer/data:ComplexObjectA ++ DATA (aspect: content) # geo:... is the path to the child nodes. # ++ creates a collection. # DATA applies the DATA definition to selected childs. # (aspect: ...) sets the setter and getter methods. } element DATA { class: ComplexObject, data:geometry/geo:polygon >> FLOAT[] (aspect: coordinates) # >> maps single child nodes. # FLOAT[] tokenizes the node text and applies FLOAT. # and so on ----- Tell me if you want to give it a try. Regards, Steffen in fact I am currently working on a library that specializes in parsing 'messy' XML. Am 25.07.2011, 15:19 Uhr, schrieb Stefan Unterweger <[hidden email]>: > Hello! > > I'm trying to work with a webservice for geospatial data. Interfacing > with it was easy, since it is WSDL. But the output format of most of the > request is a rather convoluted mess of XML namespaces nested into each > other, and I am not able to get a XML->Smalltalk-Binding working for it. > The WSDL description is very badly formed, and describes the return type > as "string", even though it is an XML document of a particular type, so > I have to do this by hand. I do not have access to the DTDs of the > various namespaces in questions, which further complicates matters. > > Maybe it's best if I start with an example: > | <?xml version='1.0' encoding='ISO-8859-1'?> > | <outer:outerContainer > | xmlns:outer="urn:outerSchema" > | xmlns:geo="urn:geoSchema"> > | xmlns:data="urn:dataSchema"> > | > | <geo:someObject> > | <geo:data>...</geo:data> > | </geo:someObject> > | > | <geo:innerContainer> > | <data:complexObjectA> > | <data:data1>...</data:data1> > | <data:data2>...</data:data2> > | <data:data3>...</data:data3> > | ... > | <data:geometry> > | <geo:polygon> > | 123.45 67.890 > | 333.22 22.888 > | ... > | </geo:polygon> > | </data:geometry> > | </data:complexObjectA> > | </geo:innerContainer> > | > | <geo:innerContainer> > | ... > | </geo:innerContainer> > | > | ... > | </outer:outerContainer> > > > On the surface, it seems rather straightforward: > I have an "outerContainer", which in turn contains some stuff, and in > particular some "innerContainer"s, which _then_ contain the real data > I'm interested in. If all of them were contained in the same namespace, > I'd already have it done and working. > > However, I haven't got a clue how to define this weird kind of > inter-namespace relations such that the XMLObjectMarshallingManager is > then able to parse such a thing. > > Til now, I've created three bindings, one for each of the schemata, > and I cross-reference the "alien" objects by explicitely including their > corresponding namespaces: > > | <?xml version="1.0" encoding="utf-8" ?> > | <schemaBindings> > | <xmlToSmalltalkBinding name="" targetNamespace="urn:schemaOuter" > xmlns:xsd="http://www.w3.org/2001/XMLSchema" > | xmlns:outer="urn:outerSchema" xmlns:geo="urn:geoSchema"> > | > | <object name="outerContainer" smalltalkClass="OuterCollection"> > | <element name="contents" ref="tns:CollectionOfOuterContainer" > aspect="contents"/> > | </object> > | <sequence_of name="CollectionOfOuterContainer"> > | <element name="contents" minOccurs="0" maxOccurs="unbounded" > ref="geo:innerContainer"/> > | </sequence_of> > | </xmlToSmalltalkBinding> > | </schemaBindings> > > Note especially the "xmlns:geo='urn:geoSchema'" to reference the second > schema. > This way the binding parses and is installed without errors (if the > bindings are loaded in the correct order). However, if I now try to > actually unmarshal something, the unmarshaller already chokes at the > <outer:outerContainer> elements, since it cannot find any > "contents"-Elements in it. > > I'm thoroughly stuck now -- I could in theory resort to do manual > parsing with XML.Parser (and in fact, this is what I began with, before > I discovered XMLObjectBinding), but it sure would be a nightmare to do > it that way. > > Basically my question is whether I'm actually on the right track, and it > is possible to construct a binding or whatever to parse such kind of > data -- without having to do it "by hand" with the XML.Parser. Or any > other hints of how to get this kind of data "into" Smalltalk with > reasonable effort. > > (If the examples are not clear, I can provide "real" data as from the > webservice -- since they are rather large I didn't want to make this > posting any longer than it already is.) > > > Many thanks in advance, > Stefan > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Hi Steffen,
* Steffen Märcker on Mon, Jul 25, 2011 at 05:25:43PM +0200: > I am not quite sure whether I understand you right. Resembles the > following structure approximately your target structure? > > (OuterContainter new) > contents: ((OrderedCollection new) > add: ComplexObject new; > ... > yourself) Yeah, that's very much like what I'd like to have at the end (give or take a few extraneous containers that are contained in the original XML). > In fact I am developing a library to map messy XML to objects, since I've > dealt too often with weird XMLs. The following binding could be a mapping > for your XML. > ----- > namespace outer="urn:outerSchema" > namespace outer="urn:geoSchema" > namespace outer="urn:dataSchema" > > root element ROOT { > class: OuterContainer, > > geo:innerContainer/data:ComplexObjectA ++ DATA (aspect: content) > # geo:... is the path to the child nodes. > # ++ creates a collection. > # DATA applies the DATA definition to selected childs. > # (aspect: ...) sets the setter and getter methods. > } > > element DATA { > class: ComplexObject, > > data:geometry/geo:polygon >> FLOAT[] (aspect: coordinates) > # >> maps single child nodes. > # FLOAT[] tokenizes the node text and applies FLOAT. > > # and so on > ----- > Tell me if you want to give it a try. >From what you've included, it looks very promising indeed; I'd certainly like to try it. s//un _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Hi Stefan,
I've published a tested but hardly documented and not feature-complete version to the public repository. The package is named SimpleXO and below you'll find an overview. I am interested in your feedback, especially comments on the readability of the mapping description and (missing) features. Regards, Steffen SimpleXO (Simple XML to Object Mapping) is a library to map weird/complex/poor XML to Objects. It does not (yet) care about generating such XML from an Object tree. The main concepts are Types and Mappings. - A type takes an XML node, creates an object and applies a set of mappings to that node. - A mapping defines which type a set of nodes is mapped to. SimpleXOParserParser class>>parse: creates a parser, that maps an XML document/node, from a mapping description. A mapping description is a String as follows. 0. Comments - # anything up to line end 1. List of namespace declarations: - namespace <prefix> = '<URI>' ... - may be empty - example: namespace w3="http://www.w3schools.com" namespace xsd="http://www.w3.org/2001/XMLSchema" 2. List of named types (cdata, element) and group declarations: - one and only one type must be marked as document root: root cdata ... or root element 2.a) CDATA - cdata <name> { class: <class_name>, constructor: <keyword> } - <name> name of type used in mappings - <class_name> - qualified for classes in namespaces other than Smalltalk - may be a shared variable - <keyword> message of class that takes a string and returns an Object - example: cdata SYMBOL {class: Symbol, constructor: intern:} 2.b) ELEMENT - element <name> { class: <class_name>, constructor: <unary>, <mappings> } - <unary> constructor message sent to class - if no constructor is provided #new is sent - if no class is provided a Dictionary (say Struct) is created - example: element INTEGER { class: Integer, constructor: fromString: } element POINT { class: Point, constructor: new, x >> INTEGER, y >> INTEGER } 2.c) MAPPING - map single element: <path> >> <type_name> <options> - map collection: <path> ++ <type_name> <options> - tokenize string-value and map each token with type: <path> >> <type_name>[] (<options>) - separated by , - <path> - similar to abbreviated relative XPath, no predicates - nodes in namespace must be prefixed - can be used in multiple mappings - <type_name> name of a declared type - >> , [] - can be used together - collection not set in parent if empty - <options> must not be provided - example: element ++ ELEMENT (aspect: elements), @attribute >> xsd:string (aspect: value), ..@id >> xsd:string, data/value >> xsd:string (aspect: rawData), data/value >> xsd:string[] (aspect: data) 2.d) OPTIONS - getter: <unary>, getter: <keyword> - use <unary> as getter, <keyword> as setter - aspect: <var> - short for "getter: <var>, setter: <var>:" - transient - apply type but do not set value in parent object - key: <name> - apply type and use value as key for parent object - transient mapping by default - reference: <name> - apply type and use value to lookup object in <name> - If aspect and getter/setter are un defined, name of the last path step is used to set value. - example: element >> ELEMENT, # == element >> ELEMENT (aspect: element) # == element >> ELEMENT (getter: element, setter: element:) element/text() >> xsd:string, # == element/text >> xsd:string (aspect: text) meta >> META (transient) # map meta elements, but do not set value in parent object @id >> xsd:string (key: ids), # id string not set in parent object @xsd:id >> xsd:string (key: ids, aspect: xsdID), # id string set in parent object @ref >> xsd:string (reference: ids), # use ref string to lookup and set a referenced object in parent 2.e) GROUPS - group { <mappings> } - syntactic sugar to reference common mappings in different types - example: namespace xsd="http://www.w3.org/2001/XMLSchema" cdata xsd:string {class: String, constructor: fromString:} group ids { @id >> xsd:string (key: ids, aspect: id), @xsd:id >> xsd:string (key: xsdIDs) } element E { # generates a struct ids, value/text() >> xsd:string } root element F { # generates a struct ids, @ref >> xsd:string (reference: ids, aspect: element) } See SimpleXOParserBuilder if you want to build a SimpleXOParser programmatically. _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
* Steffen Märcker on Tue, Jul 26, 2011 at 03:19:26PM +0200:
> I've published a tested but hardly documented and not feature-complete > version to the public repository. The package is named SimpleXO and below > you'll find an overview. I am interested in your feedback, especially > comments on the readability of the mapping description and (missing) > features. Thanks. I'll give it a try today or tomorrow, and get back to you then. Cheers, Stefan _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Steffen Märcker
What is the license of the package?
Cheers, Doru On 26 Jul 2011, at 15:19, Steffen Märcker wrote: > Hi Stefan, > > I've published a tested but hardly documented and not feature-complete > version to the public repository. The package is named SimpleXO and below > you'll find an overview. I am interested in your feedback, especially > comments on the readability of the mapping description and (missing) > features. > > Regards, Steffen > > > SimpleXO (Simple XML to Object Mapping) is a library to map > weird/complex/poor XML to Objects. It does not (yet) care about generating > such XML from an Object tree. The main concepts are Types and Mappings. > - A type takes an XML node, creates an object and applies a set of > mappings to that node. > - A mapping defines which type a set of nodes is mapped to. > > SimpleXOParserParser class>>parse: creates a parser, that maps an XML > document/node, from a mapping description. A mapping description is a > String as follows. > > 0. Comments > - # anything up to line end > > 1. List of namespace declarations: > - namespace <prefix> = '<URI>' ... > - may be empty > - example: > namespace w3="http://www.w3schools.com" > namespace xsd="http://www.w3.org/2001/XMLSchema" > > > 2. List of named types (cdata, element) and group declarations: > - one and only one type must be marked as document root: > root cdata ... or > root element > > 2.a) CDATA > - cdata <name> { class: <class_name>, constructor: <keyword> } > - <name> name of type used in mappings > - <class_name> > - qualified for classes in namespaces other than Smalltalk > - may be a shared variable > - <keyword> message of class that takes a string and returns an Object > - example: > cdata SYMBOL {class: Symbol, constructor: intern:} > > 2.b) ELEMENT > - element <name> { class: <class_name>, constructor: <unary>, <mappings> } > - <unary> constructor message sent to class > - if no constructor is provided #new is sent > - if no class is provided a Dictionary (say Struct) is created > - example: > element INTEGER { class: Integer, constructor: fromString: } > element POINT { > class: Point, > constructor: new, > x >> INTEGER, > y >> INTEGER } > > 2.c) MAPPING > - map single element: > <path> >> <type_name> <options> > - map collection: > <path> ++ <type_name> <options> > - tokenize string-value and map each token with type: > <path> >> <type_name>[] (<options>) > - separated by , > - <path> > - similar to abbreviated relative XPath, no predicates > - nodes in namespace must be prefixed > - can be used in multiple mappings > - <type_name> name of a declared type > - >> , [] > - can be used together > - collection not set in parent if empty > - <options> must not be provided > - example: > element ++ ELEMENT (aspect: elements), > @attribute >> xsd:string (aspect: value), > ..@id >> xsd:string, > data/value >> xsd:string (aspect: rawData), > data/value >> xsd:string[] (aspect: data) > > 2.d) OPTIONS > - getter: <unary>, getter: <keyword> > - use <unary> as getter, <keyword> as setter > - aspect: <var> > - short for "getter: <var>, setter: <var>:" > - transient > - apply type but do not set value in parent object > - key: <name> > - apply type and use value as key for parent object > - transient mapping by default > - reference: <name> > - apply type and use value to lookup object in <name> > - If aspect and getter/setter are un defined, > name of the last path step is used to set value. > - example: > element >> ELEMENT, > # == element >> ELEMENT (aspect: element) > # == element >> ELEMENT (getter: element, setter: element:) > element/text() >> xsd:string, > # == element/text >> xsd:string (aspect: text) > meta >> META (transient) > # map meta elements, but do not set value in parent object > @id >> xsd:string (key: ids), > # id string not set in parent object > @xsd:id >> xsd:string (key: ids, aspect: xsdID), > # id string set in parent object > @ref >> xsd:string (reference: ids), > # use ref string to lookup and set a referenced object in parent > > 2.e) GROUPS > - group { <mappings> } > - syntactic sugar to reference common mappings in different types > - example: > namespace xsd="http://www.w3.org/2001/XMLSchema" > > cdata xsd:string {class: String, constructor: fromString:} > > group ids { > @id >> xsd:string (key: ids, aspect: id), > @xsd:id >> xsd:string (key: xsdIDs) > } > > element E { > # generates a struct > ids, > value/text() >> xsd:string > } > > root element F { > # generates a struct > ids, > @ref >> xsd:string (reference: ids, aspect: element) > } > > See SimpleXOParserBuilder if you want to build a SimpleXOParser > programmatically. > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc -- www.tudorgirba.com "What is more important: To be happy, or to make happy?" _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Dear Doru,
the license is MIT which gives you much freedom in commercial and non-commercial projects as well. Please see the license tab in RBBrowser for details. I'd like to get your feedback to improve SimpleXO on its way to 1.0. If you want to contribute, please contact me in order to avoid conflicting changes. Once 1.0 is reached, I'll consider a port to Pharo, Squeak (and Java if possible) - dependent on the feedback of the community. Cheers, Steffen Am 26.07.2011, 21:08 Uhr, schrieb Tudor Girba <[hidden email]>: > What is the license of the package? > > Cheers, > Doru > > > On 26 Jul 2011, at 15:19, Steffen Märcker wrote: > >> Hi Stefan, >> >> I've published a tested but hardly documented and not feature-complete >> version to the public repository. The package is named SimpleXO and >> below >> you'll find an overview. I am interested in your feedback, especially >> comments on the readability of the mapping description and (missing) >> features. >> >> Regards, Steffen >> >> >> SimpleXO (Simple XML to Object Mapping) is a library to map >> weird/complex/poor XML to Objects. It does not (yet) care about >> generating >> such XML from an Object tree. The main concepts are Types and Mappings. >> - A type takes an XML node, creates an object and applies a set of >> mappings to that node. >> - A mapping defines which type a set of nodes is mapped to. >> >> SimpleXOParserParser class>>parse: creates a parser, that maps an XML >> document/node, from a mapping description. A mapping description is a >> String as follows. >> >> 0. Comments >> - # anything up to line end >> >> 1. List of namespace declarations: >> - namespace <prefix> = '<URI>' ... >> - may be empty >> - example: >> namespace w3="http://www.w3schools.com" >> namespace xsd="http://www.w3.org/2001/XMLSchema" >> >> >> 2. List of named types (cdata, element) and group declarations: >> - one and only one type must be marked as document root: >> root cdata ... or >> root element >> >> 2.a) CDATA >> - cdata <name> { class: <class_name>, constructor: <keyword> } >> - <name> name of type used in mappings >> - <class_name> >> - qualified for classes in namespaces other than Smalltalk >> - may be a shared variable >> - <keyword> message of class that takes a string and returns an Object >> - example: >> cdata SYMBOL {class: Symbol, constructor: intern:} >> >> 2.b) ELEMENT >> - element <name> { class: <class_name>, constructor: <unary>, >> <mappings> } >> - <unary> constructor message sent to class >> - if no constructor is provided #new is sent >> - if no class is provided a Dictionary (say Struct) is created >> - example: >> element INTEGER { class: Integer, constructor: fromString: } >> element POINT { >> class: Point, >> constructor: new, >> x >> INTEGER, >> y >> INTEGER } >> >> 2.c) MAPPING >> - map single element: >> <path> >> <type_name> <options> >> - map collection: >> <path> ++ <type_name> <options> >> - tokenize string-value and map each token with type: >> <path> >> <type_name>[] (<options>) >> - separated by , >> - <path> >> - similar to abbreviated relative XPath, no predicates >> - nodes in namespace must be prefixed >> - can be used in multiple mappings >> - <type_name> name of a declared type >> - >> , [] >> - can be used together >> - collection not set in parent if empty >> - <options> must not be provided >> - example: >> element ++ ELEMENT (aspect: elements), >> @attribute >> xsd:string (aspect: value), >> ..@id >> xsd:string, >> data/value >> xsd:string (aspect: rawData), >> data/value >> xsd:string[] (aspect: data) >> >> 2.d) OPTIONS >> - getter: <unary>, getter: <keyword> >> - use <unary> as getter, <keyword> as setter >> - aspect: <var> >> - short for "getter: <var>, setter: <var>:" >> - transient >> - apply type but do not set value in parent object >> - key: <name> >> - apply type and use value as key for parent object >> - transient mapping by default >> - reference: <name> >> - apply type and use value to lookup object in <name> >> - If aspect and getter/setter are un defined, >> name of the last path step is used to set value. >> - example: >> element >> ELEMENT, >> # == element >> ELEMENT (aspect: element) >> # == element >> ELEMENT (getter: element, setter: element:) >> element/text() >> xsd:string, >> # == element/text >> xsd:string (aspect: text) >> meta >> META (transient) >> # map meta elements, but do not set value in parent object >> @id >> xsd:string (key: ids), >> # id string not set in parent object >> @xsd:id >> xsd:string (key: ids, aspect: xsdID), >> # id string set in parent object >> @ref >> xsd:string (reference: ids), >> # use ref string to lookup and set a referenced object in parent >> >> 2.e) GROUPS >> - group { <mappings> } >> - syntactic sugar to reference common mappings in different types >> - example: >> namespace xsd="http://www.w3.org/2001/XMLSchema" >> >> cdata xsd:string {class: String, constructor: fromString:} >> >> group ids { >> @id >> xsd:string (key: ids, aspect: id), >> @xsd:id >> xsd:string (key: xsdIDs) >> } >> >> element E { >> # generates a struct >> ids, >> value/text() >> xsd:string >> } >> >> root element F { >> # generates a struct >> ids, >> @ref >> xsd:string (reference: ids, aspect: element) >> } >> >> See SimpleXOParserBuilder if you want to build a SimpleXOParser >> programmatically. >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > > -- > www.tudorgirba.com > > "What is more important: To be happy, or to make happy?" > > > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Steffen Märcker
Hi,
I've published an update (0.7.7.1) including a new feature: - allow mappings in CDATA types, e.g. to reference Strings - removed SimpleXOParserBuilder>>defineRoot: and >>parser - added SimpleXOParserBuilder>>parserForRoot: - updated package comment Cheers! Steffen Am 26.07.2011, 15:19 Uhr, schrieb Steffen Märcker <[hidden email]>: > Hi Stefan, > > I've published a tested but hardly documented and not feature-complete > version to the public repository. The package is named SimpleXO and below > you'll find an overview. I am interested in your feedback, especially > comments on the readability of the mapping description and (missing) > features. > > Regards, Steffen > > > SimpleXO (Simple XML to Object Mapping) is a library to map > weird/complex/poor XML to Objects. It does not (yet) care about > generating > such XML from an Object tree. The main concepts are Types and Mappings. > - A type takes an XML node, creates an object and applies a set of > mappings to that node. > - A mapping defines which type a set of nodes is mapped to. > > SimpleXOParserParser class>>parse: creates a parser, that maps an XML > document/node, from a mapping description. A mapping description is a > String as follows. > > 0. Comments > - # anything up to line end > > 1. List of namespace declarations: > - namespace <prefix> = '<URI>' ... > - may be empty > - example: > namespace w3="http://www.w3schools.com" > namespace xsd="http://www.w3.org/2001/XMLSchema" > > > 2. List of named types (cdata, element) and group declarations: > - one and only one type must be marked as document root: > root cdata ... or > root element > > 2.a) CDATA > - cdata <name> { class: <class_name>, constructor: <keyword> } > - <name> name of type used in mappings > - <class_name> > - qualified for classes in namespaces other than Smalltalk > - may be a shared variable > - <keyword> message of class that takes a string and returns an Object > - example: > cdata SYMBOL {class: Symbol, constructor: intern:} > > 2.b) ELEMENT > - element <name> { class: <class_name>, constructor: <unary>, <mappings> > } > - <unary> constructor message sent to class > - if no constructor is provided #new is sent > - if no class is provided a Dictionary (say Struct) is created > - example: > element INTEGER { class: Integer, constructor: fromString: } > element POINT { > class: Point, > constructor: new, > x >> INTEGER, > y >> INTEGER } > > 2.c) MAPPING > - map single element: > <path> >> <type_name> <options> > - map collection: > <path> ++ <type_name> <options> > - tokenize string-value and map each token with type: > <path> >> <type_name>[] (<options>) > - separated by , > - <path> > - similar to abbreviated relative XPath, no predicates > - nodes in namespace must be prefixed > - can be used in multiple mappings > - <type_name> name of a declared type > - >> , [] > - can be used together > - collection not set in parent if empty > - <options> must not be provided > - example: > element ++ ELEMENT (aspect: elements), > @attribute >> xsd:string (aspect: value), > ..@id >> xsd:string, > data/value >> xsd:string (aspect: rawData), > data/value >> xsd:string[] (aspect: data) > > 2.d) OPTIONS > - getter: <unary>, getter: <keyword> > - use <unary> as getter, <keyword> as setter > - aspect: <var> > - short for "getter: <var>, setter: <var>:" > - transient > - apply type but do not set value in parent object > - key: <name> > - apply type and use value as key for parent object > - transient mapping by default > - reference: <name> > - apply type and use value to lookup object in <name> > - If aspect and getter/setter are un defined, > name of the last path step is used to set value. > - example: > element >> ELEMENT, > # == element >> ELEMENT (aspect: element) > # == element >> ELEMENT (getter: element, setter: element:) > element/text() >> xsd:string, > # == element/text >> xsd:string (aspect: text) > meta >> META (transient) > # map meta elements, but do not set value in parent object > @id >> xsd:string (key: ids), > # id string not set in parent object > @xsd:id >> xsd:string (key: ids, aspect: xsdID), > # id string set in parent object > @ref >> xsd:string (reference: ids), > # use ref string to lookup and set a referenced object in parent > > 2.e) GROUPS > - group { <mappings> } > - syntactic sugar to reference common mappings in different types > - example: > namespace xsd="http://www.w3.org/2001/XMLSchema" > > cdata xsd:string {class: String, constructor: fromString:} > > group ids { > @id >> xsd:string (key: ids, aspect: id), > @xsd:id >> xsd:string (key: xsdIDs) > } > > element E { > # generates a struct > ids, > value/text() >> xsd:string > } > > root element F { > # generates a struct > ids, > @ref >> xsd:string (reference: ids, aspect: element) > } > > See SimpleXOParserBuilder if you want to build a SimpleXOParser > programmatically. > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Steffen Märcker
Hi,
On 27 Jul 2011, at 08:01, Steffen Märcker wrote: > Dear Doru, > > the license is MIT which gives you much freedom in commercial and > non-commercial projects as well. Please see the license tab in RBBrowser > for details. Thanks. That sounds great :). > I'd like to get your feedback to improve SimpleXO on its way to 1.0. If > you want to contribute, please contact me in order to avoid conflicting > changes. Once 1.0 is reached, I'll consider a port to Pharo, Squeak (and > Java if possible) - dependent on the feedback of the community. I did not take a look at the current implementation yet, but I am interested in this work in the context of Moose in Pharo. I promise I will follow it :) Cheers, Doru > Cheers, Steffen > > > > Am 26.07.2011, 21:08 Uhr, schrieb Tudor Girba <[hidden email]>: > >> What is the license of the package? >> >> Cheers, >> Doru >> >> >> On 26 Jul 2011, at 15:19, Steffen Märcker wrote: >> >>> Hi Stefan, >>> >>> I've published a tested but hardly documented and not feature-complete >>> version to the public repository. The package is named SimpleXO and >>> below >>> you'll find an overview. I am interested in your feedback, especially >>> comments on the readability of the mapping description and (missing) >>> features. >>> >>> Regards, Steffen >>> >>> >>> SimpleXO (Simple XML to Object Mapping) is a library to map >>> weird/complex/poor XML to Objects. It does not (yet) care about >>> generating >>> such XML from an Object tree. The main concepts are Types and Mappings. >>> - A type takes an XML node, creates an object and applies a set of >>> mappings to that node. >>> - A mapping defines which type a set of nodes is mapped to. >>> >>> SimpleXOParserParser class>>parse: creates a parser, that maps an XML >>> document/node, from a mapping description. A mapping description is a >>> String as follows. >>> >>> 0. Comments >>> - # anything up to line end >>> >>> 1. List of namespace declarations: >>> - namespace <prefix> = '<URI>' ... >>> - may be empty >>> - example: >>> namespace w3="http://www.w3schools.com" >>> namespace xsd="http://www.w3.org/2001/XMLSchema" >>> >>> >>> 2. List of named types (cdata, element) and group declarations: >>> - one and only one type must be marked as document root: >>> root cdata ... or >>> root element >>> >>> 2.a) CDATA >>> - cdata <name> { class: <class_name>, constructor: <keyword> } >>> - <name> name of type used in mappings >>> - <class_name> >>> - qualified for classes in namespaces other than Smalltalk >>> - may be a shared variable >>> - <keyword> message of class that takes a string and returns an Object >>> - example: >>> cdata SYMBOL {class: Symbol, constructor: intern:} >>> >>> 2.b) ELEMENT >>> - element <name> { class: <class_name>, constructor: <unary>, >>> <mappings> } >>> - <unary> constructor message sent to class >>> - if no constructor is provided #new is sent >>> - if no class is provided a Dictionary (say Struct) is created >>> - example: >>> element INTEGER { class: Integer, constructor: fromString: } >>> element POINT { >>> class: Point, >>> constructor: new, >>> x >> INTEGER, >>> y >> INTEGER } >>> >>> 2.c) MAPPING >>> - map single element: >>> <path> >> <type_name> <options> >>> - map collection: >>> <path> ++ <type_name> <options> >>> - tokenize string-value and map each token with type: >>> <path> >> <type_name>[] (<options>) >>> - separated by , >>> - <path> >>> - similar to abbreviated relative XPath, no predicates >>> - nodes in namespace must be prefixed >>> - can be used in multiple mappings >>> - <type_name> name of a declared type >>> - >> , [] >>> - can be used together >>> - collection not set in parent if empty >>> - <options> must not be provided >>> - example: >>> element ++ ELEMENT (aspect: elements), >>> @attribute >> xsd:string (aspect: value), >>> ..@id >> xsd:string, >>> data/value >> xsd:string (aspect: rawData), >>> data/value >> xsd:string[] (aspect: data) >>> >>> 2.d) OPTIONS >>> - getter: <unary>, getter: <keyword> >>> - use <unary> as getter, <keyword> as setter >>> - aspect: <var> >>> - short for "getter: <var>, setter: <var>:" >>> - transient >>> - apply type but do not set value in parent object >>> - key: <name> >>> - apply type and use value as key for parent object >>> - transient mapping by default >>> - reference: <name> >>> - apply type and use value to lookup object in <name> >>> - If aspect and getter/setter are un defined, >>> name of the last path step is used to set value. >>> - example: >>> element >> ELEMENT, >>> # == element >> ELEMENT (aspect: element) >>> # == element >> ELEMENT (getter: element, setter: element:) >>> element/text() >> xsd:string, >>> # == element/text >> xsd:string (aspect: text) >>> meta >> META (transient) >>> # map meta elements, but do not set value in parent object >>> @id >> xsd:string (key: ids), >>> # id string not set in parent object >>> @xsd:id >> xsd:string (key: ids, aspect: xsdID), >>> # id string set in parent object >>> @ref >> xsd:string (reference: ids), >>> # use ref string to lookup and set a referenced object in parent >>> >>> 2.e) GROUPS >>> - group { <mappings> } >>> - syntactic sugar to reference common mappings in different types >>> - example: >>> namespace xsd="http://www.w3.org/2001/XMLSchema" >>> >>> cdata xsd:string {class: String, constructor: fromString:} >>> >>> group ids { >>> @id >> xsd:string (key: ids, aspect: id), >>> @xsd:id >> xsd:string (key: xsdIDs) >>> } >>> >>> element E { >>> # generates a struct >>> ids, >>> value/text() >> xsd:string >>> } >>> >>> root element F { >>> # generates a struct >>> ids, >>> @ref >> xsd:string (reference: ids, aspect: element) >>> } >>> >>> See SimpleXOParserBuilder if you want to build a SimpleXOParser >>> programmatically. >>> _______________________________________________ >>> vwnc mailing list >>> [hidden email] >>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc >> >> -- >> www.tudorgirba.com >> >> "What is more important: To be happy, or to make happy?" >> >> >> _______________________________________________ >> vwnc mailing list >> [hidden email] >> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc -- www.tudorgirba.com "Problem solving efficiency grows with the abstractness level of problem understanding." _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Steffen Märcker
* Steffen Märcker on Wed, Jul 27, 2011 at 08:01:49AM +0200:
> I'd like to get your feedback to improve SimpleXO on its way to 1.0. If > you want to contribute, please contact me in order to avoid conflicting > changes. Once 1.0 is reached, I'll consider a port to Pharo, Squeak (and > Java if possible) - dependent on the feedback of the community. Nifty! :o) I've now finally had the time to try it out. It was a bit difficult to get a knack of the syntax at first, but that's mostly due to the terse documentation. But by looking at some of the tests I finally was able to understand how it is intended to work. :o) Once past this, it worked like a real charm. With just half a screenful of a binding, I was able to get a "proof of concept" of my convoluted XMLfrom my original post into Smalltalk, and in a very nifty way. Now I'll just have to flesh out the binding to include the rest of the data that I've left out for this initial attempt. I still have to understand a few of the options, so I'll play around a little bit more. Then I'll give a more thorough feedback. :o) s//un _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Hi Stefan,
thanks for your kind feedback. You are certainly right, the documentation is rudimentary, at best. I'd ask you whether you could provide your mapping as example/tutorial after you've successfully finished it. Meanwhile some comment on the options. - "getter:" remained from an early version where I planned to map Objects to XML as well. Perhaps this will happen in a 2.x, but currently this message is not used. - "key:<name>" and "reference:<name>" use <name> to define a bunch of keys. This is useful to distinguish different Elements (Types) if a common ID attribute is used in the XML. - "transient" is a flag you can use to create an object but assign it only where it is actually referenced. Example XML: ------------ <root> <complex> <objects idrefs="2 1"/> <things>3</things> </complex> <obj id="1">obj 1</obj> <obj id="2">obj 2</obj> <thing id="3">thing 1</thing> <thing id="4">thing 2</thing> </root> Example Mapping (using structs): -------------------------------- # syntax change: ; instead of , root element Complex { # no class -> struct root/complex/objects@idrefs >> String[] (reference: objects; aspect: objects); root/complex/things >> String[] (reference: things); root/obj >> Object (transient); root/thing >> Thing (transient) } cdata Object { # no class -> String @id >> String (key: objects) } cdata Thing { # no class -> String @id >> String (key: things) } cdata String { # no class -> String } Result: ------- (Dictionary new) at: #objects put: (OrderedCollection with: 'obj 2' with: 'obj 1'); at: #things put: (OrderedCollection with: 'thing 1'); yourself Ciao, Steffen _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Steffen Märcker
Hi,
I've just published a new version (7.7.5) that supports binary selectors for constructor and setter messages. There is a small syntax change, too: - Use ; instead of , to separate multiple options and definitions in types. Regards, Steffen Am 26.07.2011, 15:19 Uhr, schrieb Steffen Märcker <[hidden email]>: > Hi Stefan, > > I've published a tested but hardly documented and not feature-complete > version to the public repository. The package is named SimpleXO and below > you'll find an overview. I am interested in your feedback, especially > comments on the readability of the mapping description and (missing) > features. > > Regards, Steffen > > > SimpleXO (Simple XML to Object Mapping) is a library to map > weird/complex/poor XML to Objects. It does not (yet) care about > generating > such XML from an Object tree. The main concepts are Types and Mappings. > - A type takes an XML node, creates an object and applies a set of > mappings to that node. > - A mapping defines which type a set of nodes is mapped to. > > SimpleXOParserParser class>>parse: creates a parser, that maps an XML > document/node, from a mapping description. A mapping description is a > String as follows. > > 0. Comments > - # anything up to line end > > 1. List of namespace declarations: > - namespace <prefix> = '<URI>' ... > - may be empty > - example: > namespace w3="http://www.w3schools.com" > namespace xsd="http://www.w3.org/2001/XMLSchema" > > > 2. List of named types (cdata, element) and group declarations: > - one and only one type must be marked as document root: > root cdata ... or > root element > > 2.a) CDATA > - cdata <name> { class: <class_name>, constructor: <keyword> } > - <name> name of type used in mappings > - <class_name> > - qualified for classes in namespaces other than Smalltalk > - may be a shared variable > - <keyword> message of class that takes a string and returns an Object > - example: > cdata SYMBOL {class: Symbol, constructor: intern:} > > 2.b) ELEMENT > - element <name> { class: <class_name>, constructor: <unary>, <mappings> > } > - <unary> constructor message sent to class > - if no constructor is provided #new is sent > - if no class is provided a Dictionary (say Struct) is created > - example: > element INTEGER { class: Integer, constructor: fromString: } > element POINT { > class: Point, > constructor: new, > x >> INTEGER, > y >> INTEGER } > > 2.c) MAPPING > - map single element: > <path> >> <type_name> <options> > - map collection: > <path> ++ <type_name> <options> > - tokenize string-value and map each token with type: > <path> >> <type_name>[] (<options>) > - separated by , > - <path> > - similar to abbreviated relative XPath, no predicates > - nodes in namespace must be prefixed > - can be used in multiple mappings > - <type_name> name of a declared type > - >> , [] > - can be used together > - collection not set in parent if empty > - <options> must not be provided > - example: > element ++ ELEMENT (aspect: elements), > @attribute >> xsd:string (aspect: value), > ..@id >> xsd:string, > data/value >> xsd:string (aspect: rawData), > data/value >> xsd:string[] (aspect: data) > > 2.d) OPTIONS > - getter: <unary>, getter: <keyword> > - use <unary> as getter, <keyword> as setter > - aspect: <var> > - short for "getter: <var>, setter: <var>:" > - transient > - apply type but do not set value in parent object > - key: <name> > - apply type and use value as key for parent object > - transient mapping by default > - reference: <name> > - apply type and use value to lookup object in <name> > - If aspect and getter/setter are un defined, > name of the last path step is used to set value. > - example: > element >> ELEMENT, > # == element >> ELEMENT (aspect: element) > # == element >> ELEMENT (getter: element, setter: element:) > element/text() >> xsd:string, > # == element/text >> xsd:string (aspect: text) > meta >> META (transient) > # map meta elements, but do not set value in parent object > @id >> xsd:string (key: ids), > # id string not set in parent object > @xsd:id >> xsd:string (key: ids, aspect: xsdID), > # id string set in parent object > @ref >> xsd:string (reference: ids), > # use ref string to lookup and set a referenced object in parent > > 2.e) GROUPS > - group { <mappings> } > - syntactic sugar to reference common mappings in different types > - example: > namespace xsd="http://www.w3.org/2001/XMLSchema" > > cdata xsd:string {class: String, constructor: fromString:} > > group ids { > @id >> xsd:string (key: ids, aspect: id), > @xsd:id >> xsd:string (key: xsdIDs) > } > > element E { > # generates a struct > ids, > value/text() >> xsd:string > } > > root element F { > # generates a struct > ids, > @ref >> xsd:string (reference: ids, aspect: element) > } > > See SimpleXOParserBuilder if you want to build a SimpleXOParser > programmatically. > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Steffen Märcker
* Steffen Märcker on Fri, Jul 29, 2011 at 10:39:05AM +0200:
> thanks for your kind feedback. You are certainly right, the documentation > is rudimentary, at best. I'd ask you whether you could provide your > mapping as example/tutorial after you've successfully finished it. > Meanwhile some comment on the options. I've already taken some notes; I'll try to compile them into a more coherent example when I'm finished. Just one further observation: When creating mappings, debugging is currently an almost painful process, since for the most parts, the only feedback the ParserParser gives is a plain "token not expected" whenever something doesn't sit well with it, without any kind of indication what exactly went wrong, and where. As a trivial example try an empty binding (where this kind of message is somewhat misguiding). I'm quite sure this is a symptom of the ParserParser being done in SmaCC, but I don't understand SmaCC well enough yet to be able to guess how to make it better. > - "getter:" remained from an early version where I planned to map Objects > to XML as well. Perhaps this will happen in a 2.x, but currently this > message is not used. Ah, good to know. I was already wondering about what the 'getter' might be used for. As far as I'm able to discern from the grammar, currently if I want to use the 'setter:' syntax, I'm forced to set a getter as well. Stefan _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Hi Stefan,
I am looking forward to your use case. I'll provide my own mappings as examples later as well. You're right, debugging a mapping is indeed painful at the moment. When the grammar has settled I'll be looking into that. Meanwhile I suggest to load "SmaCC Development UI" (v 1.07) and to use "Tools>>SmaCC Parser Generator". It has a test tab which shows at which position an error occurred. I think the getter option has a good chance to vanish in the next versions. =) How do you think about >>, ++ and [] for single/collection/tokenized mappings? Regards, Steffen Am 29.07.2011, 16:05 Uhr, schrieb Stefan Unterweger <[hidden email]>: > * Steffen Märcker on Fri, Jul 29, 2011 at 10:39:05AM +0200: >> thanks for your kind feedback. You are certainly right, the >> documentation >> is rudimentary, at best. I'd ask you whether you could provide your >> mapping as example/tutorial after you've successfully finished it. >> Meanwhile some comment on the options. > > I've already taken some notes; I'll try to compile them into a more > coherent example when I'm finished. > > Just one further observation: When creating mappings, debugging is > currently an almost painful process, since for the most parts, the only > feedback the ParserParser gives is a plain "token not expected" whenever > something doesn't sit well with it, without any kind of indication what > exactly went wrong, and where. As a trivial example try an empty > binding (where this kind of message is somewhat misguiding). > > I'm quite sure this is a symptom of the ParserParser being done in > SmaCC, but I don't understand SmaCC well enough yet to be able to guess > how to make it better. > >> - "getter:" remained from an early version where I planned to map >> Objects >> to XML as well. Perhaps this will happen in a 2.x, but currently this >> message is not used. > > Ah, good to know. I was already wondering about what the 'getter' might > be used for. > As far as I'm able to discern from the grammar, currently if I want to > use the 'setter:' syntax, I'm forced to set a getter as well. > > > Stefan > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Stefan Unterweger
Hi,
I've just published a new version that removes support for the 'getter:' option. (Thanks Stefan!) Use either path >> type (setter: <one_arg_msg> ... or path >> type (aspect: <var_name> ... . (aspect: <var_name>) is another form to write (setter: <var_name>:). It reads better in context of structs (imho), where <var_name> gives the key. In contrast, (setter: <one_arg_msg>) handles even binary messages. If applied in structs, the key will be the binary message itself or the keyword without $:. Have fun! Steffen Am 29.07.2011, 16:05 Uhr, schrieb Stefan Unterweger <[hidden email]>: > * Steffen Märcker on Fri, Jul 29, 2011 at 10:39:05AM +0200: >> thanks for your kind feedback. You are certainly right, the >> documentation >> is rudimentary, at best. I'd ask you whether you could provide your >> mapping as example/tutorial after you've successfully finished it. >> Meanwhile some comment on the options. > > I've already taken some notes; I'll try to compile them into a more > coherent example when I'm finished. > > Just one further observation: When creating mappings, debugging is > currently an almost painful process, since for the most parts, the only > feedback the ParserParser gives is a plain "token not expected" whenever > something doesn't sit well with it, without any kind of indication what > exactly went wrong, and where. As a trivial example try an empty > binding (where this kind of message is somewhat misguiding). > > I'm quite sure this is a symptom of the ParserParser being done in > SmaCC, but I don't understand SmaCC well enough yet to be able to guess > how to make it better. > >> - "getter:" remained from an early version where I planned to map >> Objects >> to XML as well. Perhaps this will happen in a 2.x, but currently this >> message is not used. > > Ah, good to know. I was already wondering about what the 'getter' might > be used for. > As far as I'm able to discern from the grammar, currently if I want to > use the 'setter:' syntax, I'm forced to set a getter as well. > > > Stefan > _______________________________________________ > vwnc mailing list > [hidden email] > http://lists.cs.uiuc.edu/mailman/listinfo/vwnc vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Steffen Märcker
Hi,
I havent't yet had time to fully explore the changes of the new version(s) yet, but I've stumbled over another thing: * Steffen Märcker on Tue, Jul 26, 2011 at 03:19:26PM +0200: > 2.c) MAPPING > - map single element: > <path> >> <type_name> <options> > - map collection: > <path> ++ <type_name> <options> > - tokenize string-value and map each token with type: > <path> >> <type_name>[] (<options>) > [...] > - separated by , As far as I gathered until now (and as written in your description), the "mappings" are formed like this: | <path> <operator> <options> With <operator> one of >>, ++, and so on, <options> as needed, and <path> an XPath expression to select the nodes upon which to operate. > - <path> > - similar to abbreviated relative XPath, no predicates > - nodes in namespace must be prefixed > - can be used in multiple mappings Apart from "no predicates", are there other restrictions? Specifically, it looks like wildcards are not supported. Given a (stupid) data file like this: | <?xml version="1.0" encoding="us-ascii" ?> | <root> | <container> | <item id="1">eins</item> | <item id="2">zwei</item> | <item id="3">drei</item> | </container> | </root> And this (equally nonsensical) mapping: | root element Root { | root/container >> Container (aspect: content) | } | | element Container { | * ++ Item (aspect: items) | } | | element Item { | class: Object | } I get the infamous "Token not expected", with the Parser complaining right at the "*". I've tried similar path expressions with the standard VisualWorks XPath facilities, and it seems the paths themselves are correct. Bye, Stefan _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Hi Stefan,
your observation is correct, SimpleXO's path expressions do not support wildcards (and absolute paths) yet. This is in the pipe for 0.8.x. Maybe you've noticed another difference. XPath selects attribute nodes with "path/@attribut", while we omit $/. This will change shortly, too. Actually, SimpleXO does not use VW's XPath library to allow syntax experiments. Regards, Steffen Am 02.08.2011, 12:34 Uhr, schrieb Stefan Unterweger <[hidden email]>: > Hi, > > I havent't yet had time to fully explore the changes of the new > version(s) yet, but I've stumbled over another thing: > > * Steffen Märcker on Tue, Jul 26, 2011 at 03:19:26PM +0200: >> 2.c) MAPPING >> - map single element: >> <path> >> <type_name> <options> >> - map collection: >> <path> ++ <type_name> <options> >> - tokenize string-value and map each token with type: >> <path> >> <type_name>[] (<options>) >> [...] >> - separated by , > > As far as I gathered until now (and as written in your description), the > "mappings" are formed like this: > | <path> <operator> <options> > > With <operator> one of >>, ++, and so on, <options> as needed, and > <path> an XPath expression to select the nodes upon which to operate. > >> - <path> >> - similar to abbreviated relative XPath, no predicates >> - nodes in namespace must be prefixed >> - can be used in multiple mappings > > Apart from "no predicates", are there other restrictions? > Specifically, it looks like wildcards are not supported. > > Given a (stupid) data file like this: > | <?xml version="1.0" encoding="us-ascii" ?> > | <root> > | <container> > | <item id="1">eins</item> > | <item id="2">zwei</item> > | <item id="3">drei</item> > | </container> > | </root> > > And this (equally nonsensical) mapping: > | root element Root { > | root/container >> Container (aspect: content) > | } > | > | element Container { > | * ++ Item (aspect: items) > | } > | > | element Item { > | class: Object > | } > > I get the infamous "Token not expected", with the Parser complaining > right at the "*". I've tried similar path expressions with the standard > VisualWorks XPath facilities, and it seems the paths themselves are > correct. > > > Bye, > Stefan vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Steffen Märcker
* Steffen Märcker on Fri, Jul 29, 2011 at 10:39:05AM +0200:
> thanks for your kind feedback. You are certainly right, the documentation > is rudimentary, at best. I'd ask you whether you could provide your > mapping as example/tutorial after you've successfully finished it. > Meanwhile some comment on the options. I started collecting your various pieces of documentation together with my examples in a little wiki at my place: -> https://wiki.aleturo.com/alpha/simplexo:start <- There isn't much there at the moment, but the more I understand, the more will be there. :o) If you want, I can setup a write account for you. Stefan _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Wow, that great - thank you very much!
Of course I'd be happy to get a write account in order to contribute to this documentation. =) Regards, Steffen Am 02.08.2011, 15:27 Uhr, schrieb Stefan Unterweger <[hidden email]>: > * Steffen Märcker on Fri, Jul 29, 2011 at 10:39:05AM +0200: >> thanks for your kind feedback. You are certainly right, the >> documentation >> is rudimentary, at best. I'd ask you whether you could provide your >> mapping as example/tutorial after you've successfully finished it. >> Meanwhile some comment on the options. > > I started collecting your various pieces of documentation together with > my examples in a little wiki at my place: > -> https://wiki.aleturo.com/alpha/simplexo:start <- > > There isn't much there at the moment, but the more I understand, the > more will be there. :o) > > If you want, I can setup a write account for you. > > > Stefan vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
In reply to this post by Steffen Märcker
Hi,
I've published SimpleXO 0.8 last week. Important changes: - select attributes: 'element/@attribute' instead of 'element@attribute' - absolute paths supported: '/element' - descendant-or-self path supported: '//@attribute' and 'element//sub' - started port from SmaCC to Xtreams PEG Parser Poll: - Do we need XPath predicates? - Do we need non-XPath name wildcards like '@data??' or 'element*' ? Regards, Steffen _______________________________________________ vwnc mailing list [hidden email] http://lists.cs.uiuc.edu/mailman/listinfo/vwnc |
Free forum by Nabble | Edit this page |