Enhancement of the XML connection

Introduce your project and write about your work.

Moderator: PPS-Leaders

User avatar
x3n
Baron Vladimir Harkonnen
Posts: 810
Joined: Mon Oct 30, 2006 5:40 pm
Contact:

Enhancement of the XML connection

Post by x3n » Sun Mar 13, 2011 10:32 pm

hi everyone!

this thread is about the XML connection in orxonox and my plans (and later hopefully also my attempts) to improve it.

after kevin started his diary about osx support, I felt motivated to start a developer's journal myself. this is merely a place for me to collect some information and to share my thoughts with you. feel free to tell me whatever you think about what I will write down here. for deep technical discussions we'll move over to the framework development forums though.


introduction
in order that everyone understands what this is about, let me start with a short introduction: orxonox uses XML for level files. we use XMLPort, a collection of macros, to parse XML files and to load objects and their attributes. additionally we use the scripting language Lua to embedd code in XML files which allows us to add randomly placed asteroids and other fancy stuff.

additionally we use templates to define objects at one location and create them at one or multiple other locations. templates are used, for example, to define the appearance and the settings of a spaceship. whenever a player spawns at a spawnpoint, the template is used to create a new ship. we use Lua to include files that contain these templates.

finally we also use XML to define HUDs. these files are in a different directory and if you want to use a certain HUD for your spaceship, you have to include this XML file in your template file (or level file) in order to create this HUD in the game.
Fabian 'x3n' Landau, Orxonox developer

User avatar
x3n
Baron Vladimir Harkonnen
Posts: 810
Joined: Mon Oct 30, 2006 5:40 pm
Contact:

Re: Enhancement of the XML connection

Post by x3n » Mon Mar 14, 2011 10:25 pm

about this thread
so why am I writing this journal? well, in the past I felt that the communication about what's going on in the framework development was not always good enough. just recently damian asked me, whether the new console command system is already in the trunk or not. well yeah, it is - for over half a year already. maybe we can avoid this lack of information if we write journals like this, because unlike a message in the IRC, it remains forever in this forum. especially now, when most of the former framework developers are not meeting every week in the PPS anymore, but only 2-3 times per year.

additionally I know that some parts of the framework are considered "my" code, and even though that's not particularly true, it still helds people from working on this code. they do, however, depend on it, as usual with a framework, and so I don't want this to look like a one-man-show because in fact I'm very thankful for every helping hand and every reasoned suggestion. that's what this thread is for, to share ideas and to keep you informed.


motivation / issues
before I start to explain you what I want to change on the XML connection in orxonox, let me first explain why I want to change it. to so, I break it down into two parts: XMLPort and XML files.

XMLPort:
Even though XMLPort is quite sufficient if you want to parse an XML file and load it into classes and variables, it still lacks a considerable amount of features.
  1. it's not yet possible to save an XML file, only loading works
  2. there is no support for something like enums, instead we have to use plain strings without any sort of validation (see for example the "type" attribute of the Light class)
  3. XMLPort allows subsections, but it doesn't allow sub-subsections (they are currently required for XML-Events, so we have to use hacks)
  4. default values for XMLPort params overwrite values set by the constructor of a child class, there's no way to change the default in a subclass.
  5. Every element in XML requires a corresponding BaseObject in orxonox, there's no way to store a single int without a helper object
  6. you can load a list of subobjects (XMLPortObject), but it's not possible to load only one single subobject (if you don't want a whole list)
  7. no references/pointers to objects are possible, except if you refer to them by name and use XMLNameListener to find it
  8. objects that need an Identifier have to load the corresponding class name as a string and then convert it to an Identifier, which requires 2 member variables instead of one. the same holds for templates
  9. to link weapon modes with firemodes, we have to use DefaultWeaponmodeLink as helper class even though it's basically just map<int, int> (a standard type)
XML:
our XML levelfiles are quite cool and with the help of triggers, states, and the XML event system we can create awesome effects. lua allows us to include templates and generating even more XML code. but there are also some issues.
  1. if you want to use a template, you have to include the corresponding file
  2. if you want to create a HUD which is defined in a XML file, you have to include it as well
  3. if you include 5 different spaceships with the same HUD, the corresponding HUD file gets included 5 times
  4. errors in XML documents are usually not understandable from the error message, and if they are, they point to the wrong line number because of includes and lua-generated XML code
  5. there's no way to refer to another object except by name (and only if this is supported by a helper class in Orxonox)
  6. you can not use XML events in templates because the name gets replicated with every instance of the template, hence the objects can not be distinguished by name
  7. we can not pass arbitrary text to a class, which would be required to store lua script code in a script object
and finally there's this one big project, which probably starts to bore you, I know, but we will still somehow somewhen implement it: an editor! and I suppose it makes absolutely sense to use XMLPort to update objects through an editor. this yields a few more issues with the current implementation of XMLPort:
  1. attributes are not directly accessible if you want to change a single value in the editor, instead the whole object has to be reloaded
  2. there is no information about the allowed values, range, or keywords (see the point about enums before) for a value
  3. XMLPortObject requires a function to add an object and to retrieve an object, but there is no interface to remove objects or to change their order in the list
  4. all possible XML elements and attributes need to be known when starting the editor, currently they are however collected on demand when the first object of a kind is loaded

so if you're still reading, you probably noticed that this list got quite long and still I feel like I missed half of the points. Next I'll tell you how I intend to fix this misery.

please leave a comment if you can think of another issue with the current implementation of XMLPort or the way we use XML files.
Fabian 'x3n' Landau, Orxonox developer

User avatar
x3n
Baron Vladimir Harkonnen
Posts: 810
Joined: Mon Oct 30, 2006 5:40 pm
Contact:

Re: Enhancement of the XML connection

Post by x3n » Wed Mar 16, 2011 8:49 pm

I think it's time to start thinking about the new XML system. instead of designing it from the C++ point of view (i.e. taking an XML parser, writing some XMLPort macros, and then see what's possible with it), I want to do this from the XML point of view. this means we'll try to design the perfect XML structure for our levels, templates, HUDs, and whatever else. then we try to implement this in C++, but that's still a long way to go.


old XML
right now the XML files look like this (simplified):

/templates/myship.oxt:

Code: Select all

<Template name="fancyship">
  <SpaceShip argument="value">
    <... />
  </SpaceShip>
</Template>
/levels/mylevel.oxw:

Code: Select all

<?lua
  include("templates/myship.oxt")
?>

<Level>
  <Scene>
    <SpaceShip position="1,2,3" template="fancyship" />
  </Scene>
</Level>
as you clearly see, there are two completely separated files, one containing a template, the other using this template in a level. the template file gets included with lua. unfortunately, the lua inclusion function is not that smart, so things get really tricky if you want to include a file that itself has another include. fortunately we have a way to use the ogre resource manager to locate files (which, less fortunately, also writes some unreasoned errors to the logfile). but still, if our list of templates grows we have to include tons of files which gets really annoying for level designers.


new XML
my vision of the new XML system is actually not that different. except that there will be only one XML file in total. virtually. in fact we will still store our levels and templates in different files in different directories, but from a system's point of view, it all looks like one big XML file.

/root.xml:

Code: Select all

<root>
  <templates>
    <myship.oxt>
      <Template name="fancyship">
        <SpaceShip argument="value">
          <... />
        </SpaceShip>
      </Template>
    </myship.oxt>
  </templates>
  <levels>
    <mylevel.oxw>
      <Level>
        <Scene>
          <SpaceShip position="1,2,3" template="/templates/myship.oxt/fancyship" />
        </Scene>
      </Level>
    </mylevel.oxw>
  </levels>
</root>
notice the two differences: first, both template and level are incorporated into the same (virtual) XML file which renders the include directive unecessary. second, the template argument is now a path instead of just a name.

just to make this clear, let me emphasize again that in fact both template and level are still stored in 2 different files (like in the first example). but when the level loading starts, all XML files in all subdirectories are virtually concatenated to one big XML file. this allows to reference every element (like templates) in every file without explicit inclusion.

now you may wonder about performance, but don't worry: of course we won't really create this big XML file in memory - instead whenever the XML parser requires an element which is in another file, we will silently load this file in the background and feed it to the parser. that way the whole thing looks like one big XML file, but in reality it isn't.

now what's the benefit of this virtual super-XML file? the benefit is that we can apply XML logic to our whole file and directory structure, thus not requiring include() anymore and leaving this burden completely to the XML parser.


...to be continued.
Fabian 'x3n' Landau, Orxonox developer

User avatar
BadElvis
Human Space Navy Lord Commander
Posts: 83
Joined: Wed Nov 14, 2007 1:07 pm
Contact:

Re: Enhancement of the XML connection

Post by BadElvis » Thu Mar 17, 2011 1:47 pm

hey there,

i am very impressed by what the new xml engine will be able to do. the level editor itself is a important step, i think, because it links the the programmer's work with the content designer's work.

i recently had a couple of thoughts on how this could be done. one key concept would surely be the introduction of xml validation with a scheme. will the new framework support xsd validation?

another thing that is a bit similar in fact is the well-formedness of the level files. it would be gread if they were valid , well-formed xml. we could use a tool to check our levels while we are writing xml. like http://www.validome.org/xml/

cheers!

User avatar
1337
Baron Vladimir Harkonnen
Posts: 521
Joined: Wed Oct 10, 2007 7:59 am

Re: Enhancement of the XML connection

Post by 1337 » Fri Mar 18, 2011 3:13 am

So would like to place a comment:

As stated above, we're currently using the Ogre resource management system to access pretty much EVERY file. That has resulted in serveral hiccoughs and even workarounds.

The advantages of this system are:
- Abstract virtual file system that can be joined together from multiple locations
- Every file could also be in an archive

While this may sound very cool, it might not actually be useful for all kinds of files.

What I'm trying to say is, we could just use normal file handling for some files if we get into big trouble with the Ogre Resource Management. So far, I've always found a solution though. But it shouldn't be a prerequisite, just a really nice to have.

But I don't really see problems with the new XML stuff in that direction. Just mentioning it so I get email notifications about this thread ^^
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.

User avatar
beni
Baron Vladimir Harkonnen
Posts: 949
Joined: Tue Oct 03, 2006 9:15 am
Location: Zurich
Contact:

Re: Enhancement of the XML connection

Post by beni » Sun Mar 20, 2011 12:59 pm

Maybe I'm missing a point, but the new proposed super-XML file that doesn't really exist, isn't really different from what we do now, except that includes are done automatically with the designer not having to worry too much about file paths and dependencies, right?

With the rest I really think it's a good idea to review the XML system. I think all of us had at least one or two problems with the system in the past. A prerequisite for the editor should be a working XML saving and loading.

Wasn't it Crysis where its developers created the editor first and the game after that? I think looking at the problem from the XML point of view is a good first step, but maybe one should take it even further and look at it from a editor's point of view and work it backwards from there.
"I'm Commander Shepard and this is my favorite forum on the internet."

User avatar
x3n
Baron Vladimir Harkonnen
Posts: 810
Joined: Mon Oct 30, 2006 5:40 pm
Contact:

Re: Enhancement of the XML connection

Post by x3n » Mon Mar 21, 2011 10:20 pm

thanks for your replies, glad to see people actually read through this wall of text ;)
BadElvis wrote:i recently had a couple of thoughts on how this could be done. one key concept would surely be the introduction of xml validation with a scheme. will the new framework support xsd validation?

another thing that is a bit similar in fact is the well-formedness of the level files. it would be gread if they were valid , well-formed xml. we could use a tool to check our levels while we are writing xml. like http://www.validome.org/xml/
yes, I consider to use validation for our level files based on an XML schema. there are two reasons for this:
1. we could use a a generic XML editor, which serves - in combination with the XML schema - as a temporary level editor until we build a graphical editor because the schema lists the possible classes and arguments.
2. if we define default values for our arguments, we should also define them in an XML schema because otherwise the XML data is incomplete (talking on the XML level - after loading the data and passing it through XMLPort, the default values will be applied, but XML knows nothing about them without an XML schema). this can be a problem when working with tools like XPath.

on the other hand, creating an XML schema is not an easy task and we don't really need it for a graphical editor. so we'll have to trade off the benefits against the amount of work which will be required to implement this.

I will talk about XML schema, XPath, and also about some other XML related techniques in a later post.

1337 wrote:As stated above, we're currently using the Ogre resource management system to access pretty much EVERY file. That has resulted in serveral hiccoughs and even workarounds.

The advantages of this system are:
- Abstract virtual file system that can be joined together from multiple locations
- Every file could also be in an archive

While this may sound very cool, it might not actually be useful for all kinds of files.

What I'm trying to say is, we could just use normal file handling for some files if we get into big trouble with the Ogre Resource Management. So far, I've always found a solution though. But it shouldn't be a prerequisite, just a really nice to have.

But I don't really see problems with the new XML stuff in that direction. Just mentioning it so I get email notifications about this thread ^^
that's right, the Ogre resources should still work with the new XML system, especially because we'll have to do some smart loading (and maybe caching) of the XML files in the background anyway, while the loader traverses the virtual XML super file.

another benefit of the ogre resource management system is, that we could distribute level packages (custom levels) in a zip file, containing the level file itself, additional templates, models, textures, etc. if we add these zip files to the resources, we could access this data as if it would be unziped in the data directory.

beni wrote:Maybe I'm missing a point, but the new proposed super-XML file that doesn't really exist, isn't really different from what we do now, except that includes are done automatically with the designer not having to worry too much about file paths and dependencies, right?
no you're not missing a point. that is exactly the point - build levels like you're used to, but don't worry about includes anymore. the super-XML files is just a possible solution how to implement this in our framework. because if we look at the directory structure as a big XML file, we can use XPath to find templates, which makes it a lot easier and especially more consistent because we could use XPath also for some other cool stuff (as noted above in response to BadElvis' question, I'll talk about this in a later post).

additionally there is actually indeed a point which makes <?lua include(...) ?> a bad thing, but I didn't explain that so far. I'll do so also in a later post. for now let's state that there is a problem with the way we're using lua in our XML files right now.

beni wrote:With the rest I really think it's a good idea to review the XML system. I think all of us had at least one or two problems with the system in the past. A prerequisite for the editor should be a working XML saving and loading.

Wasn't it Crysis where its developers created the editor first and the game after that? I think looking at the problem from the XML point of view is a good first step, but maybe one should take it even further and look at it from a editor's point of view and work it backwards from there.
that's a good point. I think every game engine starts with an editor. some game developers maybe also use their 3d modelling tool to assemble the first levels, but at some point you definitely need an editor. I recently read a long story about the development of the unreal engine. and guess what, it all started off with an editor. :)

and you're right, we shouldn't design everything in a way which allows nice XML files. what I'm trying to say is, that everything should be possible in XML. because no matter how smart and fancy your editor will be, you still have to save the level as an XML file. and if we know what we need in XML, we can build XMLPort. that's the current goal.

that's why I look at the problem from the XML point of view, but of course I keep in mind that in future building levels will be more of a point & click task
Fabian 'x3n' Landau, Orxonox developer

User avatar
1337
Baron Vladimir Harkonnen
Posts: 521
Joined: Wed Oct 10, 2007 7:59 am

Re: Enhancement of the XML connection

Post by 1337 » Tue Mar 22, 2011 1:33 pm

Might there be a way to extend the definitions in the XMLPort functions slightly so that we can automatically generate schema files?
I'm sure you've thought about this, hence there has to be a good reason why it's not possible. But I can't think of one within a minute ;)
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.

User avatar
x3n
Baron Vladimir Harkonnen
Posts: 810
Joined: Mon Oct 30, 2006 5:40 pm
Contact:

Re: Enhancement of the XML connection

Post by x3n » Tue Mar 22, 2011 7:29 pm

yes that's exactly the plan, but it's still not easy since we have to define the whole class hierarchy including inheritance and possibly also interfaces in the schema. and if we want to export containers like vectors or maps to XML, we have to define them as well. additionally we need to define all the constraints, for example a quaternion shouldn't just be defined as four floats, instead it should describe a valid rotation of the object. templates are currently handled as "a string which looks like XML" inside the template element. if we use an XML schema, templates will also undergo the validation, which may be a problem, for example if they are incomplete. if we use event sources and event listeners, the valid arguments for those are currently limited to the names of other objects. how to define that in an XML schema? etc etc etc ;)
Fabian 'x3n' Landau, Orxonox developer

User avatar
1337
Baron Vladimir Harkonnen
Posts: 521
Joined: Wed Oct 10, 2007 7:59 am

Re: Enhancement of the XML connection

Post by 1337 » Tue Mar 22, 2011 7:48 pm

Hmm ;)
I guess we probably need a mixture: define as much as possible (with some common sense) in the schema file (*.xsd I suppose) and do the rest within C++.

Does tinyxml support schemas?
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.

User avatar
x3n
Baron Vladimir Harkonnen
Posts: 810
Joined: Mon Oct 30, 2006 5:40 pm
Contact:

Re: Enhancement of the XML connection

Post by x3n » Tue Mar 22, 2011 8:46 pm

1337 wrote:Hmm ;)
I guess we probably need a mixture: define as much as possible (with some common sense) in the schema file (*.xsd I suppose) and do the rest within C++.
yes absolutely. as I stated in my answer to BadElvis' question, validation is not necessarily required. just defining the default values could be enough. in fact it also works without any sort of validation, but maybe it is nice to have it to some extends. however the more validation we can perform, the easier it is to use a general purpose XML editor for level files. which is exactly the trade off I talked about.
Does tinyxml support schemas?
no. here's a short overview over some XML parsers I found (to be honest, I just looked at the parsers which are supported by cegui, but maybe you can point me out to some other libraries).
  • TinyXML is the parser we currently use in orxonox, together with it's c++ frontend, TiCPP. There's also a project called TinyXPath which implements XPath, but I'm not sure if it uses TinyXML or if they just have similar names. TinyXML itself supports plain DOM-like XML parsing. Works good at the moment but is probably not enough in future.
  • RapidXml claims to be a very fast XML parser, but with only little features (and if it's fast, it probably also lacks some validation, i.e. <hello></world> would probably work, simply because it doesn't care.) has not enough features for my needs.
  • expat seems to be a simple parser with a SAX-like interface. it's quite old (a good thing) and has lots of derived 3rd party wrappers, but it's probably too scattered to be used in orxonox.
  • xerces is built in C++ (seem's to be rare among xml parsers, so thats a plus) which supports - apart from DOM and SAX parsing - XML schema, XML namespace, and XInclude. unfortunately it doesn't seem to support XPath.
  • Libxml2 seems to be the largest of all presented XML parsers, written in C, available on basically all systems. Supports a number of features, including DOM and SAX parsing, XML Namespace, XInclude, XPath, XPointer, and (experimental?) XMLSchema. DTD seems to be better supported than XML schema though. this is currently my favorite library.
note: I added a lot of links to wikipedia to explain all the XML concepts. I'll explain them in a later post, for now we can just assume that some of them may be useful for our needs, but not necessary.
Fabian 'x3n' Landau, Orxonox developer

User avatar
1337
Baron Vladimir Harkonnen
Posts: 521
Joined: Wed Oct 10, 2007 7:59 am

Re: Enhancement of the XML connection

Post by 1337 » Tue Mar 22, 2011 8:58 pm

http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.

User avatar
1337
Baron Vladimir Harkonnen
Posts: 521
Joined: Wed Oct 10, 2007 7:59 am

Re: Enhancement of the XML connection

Post by 1337 » Sun Apr 03, 2011 12:25 am

I've found one more XML library, but I haven't checked it out at all: POCO also has an XML library.
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.

User avatar
x3n
Baron Vladimir Harkonnen
Posts: 810
Joined: Mon Oct 30, 2006 5:40 pm
Contact:

Re: Enhancement of the XML connection

Post by x3n » Sat Apr 16, 2011 8:58 pm

Yes indeed, I forgot the XML parsers that are part of bigger libraries:
  • POCO XML Parser: Has a DOM- and a SAX-like parser and seemingly supports DTD validation.
  • Boost Property Tree: Wraps RapidXML (described above), so not really interesting.


Out of your other links, Bare XML is the only real XML parser, which looks pretty basic. It supports some sort of validation, but it's probably a non-standard format. CodeSynthesis XSD is a code generator, VTD-XML is a language based on XML.


Now while we're still talking about XML parsers and the different features they support, I think it's about time to give you an overview of some of the existing XML technologies. In fact I originally wanted to explain them before discussing XML parsers, but the topic came up in the thread, so we have to catch up on this now.

XML (wikipedia)
Description: XML is a text based markup language, used to exchange structured data between programs and users in a human readable format. XML is probably most prominently used in HTML. In XML, objects are represented by "elements". Each element can possess attributes and sub-objects.
Syntax:
Element: <Element /> or <Element></Element>
Subelement: <Element><Subelement /></Element>
Attribute: <Element attribute="value" />
Processing instruction <?name instruction ?>
Comment: <!-- comment -->
Usage in Orxonox: We use XML elements to represent our objects and attributes to represent their values. Processing instructions are currently not used (even though our lua tags follow the same syntax, they are processed by our own parser before the XML parser even touches the document). I recommend to parse lua with the XML parser in future, even though that will require some heavy changes (but lua in general is part of a future post in this thread).

CDATA (wikipedia)
Description: CDATA is short for character data and allows insertion of arbitrary text/data in XML. Because this usually conflicts with the XML syntax, CDATA provides a separated element which automatically escapes all characters that have a meaning to XML (like <, >, ", etc).
Syntax: <![CDATA[arbitrary text or code]]>
Usage in Orxonox: Could be used to define lua scripts in XML that should not be parsed while loading the level, but rather be passed to a "script" object. Could also be an alternative way to define templates.

XML Namespace (wikipedia)
Description: Like in C++, namespaces in XML allow to have different elements and attributes with the same name, but different namespace, hence preserving distinguishability.
Syntax: <Element namespace:attribute="value" />
There are different ways to use a namespace, but this is probably the most convenient way if used in different places across the XML file. Additionally namespaces have to be defined before usage.
Usage in Orxonox: I see a possible usage for this technique in the editor: we could save meta-data for each object, that is only relevant for the editor. For example, you could make some objects invisible in the editor (only in the editor, not in the game), which would be saved with a editor:visible="false" attribute. By using the "editor" namespace, the attribute doesn't collide with the "visible" attribute of BaseObject.

XPath (wikipedia)
Description: XPath is a way to gather information from an XML file. With XPath you can retrieve an element with given attributes, list all elements of some type, get the number of subelements of an element, the value of an attribute of some element, etc.
Syntax: (no guarantee for correct syntax since I neither know XPath nor have a way to test it, but you should get a pretty good impression)
/a/b/text() # returns the text-value of "b" (which is a sub-element of "a")
/a/b[@attribute=value] # returns all elements of type "b" which are a sub-elements of "a" and have "attribute" with value "value"
count(a/*) # counts all sub-elements of "a"
Usage in Orxonox: Wherever we reference an object in XML, we currently use it's name (which is not a completely satisfying solution). This happens when we use a template, connect events and listeners, and probably some more occasions. XPath could be a convenient and powerful way to reference an object or a set of objects. Its query language allows to select specific objects, e.g. all objects within a given range of positions.

DTD Validation (wikipedia)
Description: Validation in general is used to define how an XML file should be built. It defines the allowed elements and their attributes, as well as sub-elements, valid ranges for values, and more. DTD is the oldest and most widely supported (in XML libraries) way to do this.
Syntax: <!ELEMENT html (head, body)> # defines that the "html" element can have "head" and "body" as sub-elements (as far as I interpret it without really knowing DTD)
Usage in Orxonox: While validation in general may be useful, I prefer XML Schema. Though, since XML parsers that support DTD are way more common, we may also use DTD if necessary. For more details about validation see the next point about XML Schema.

XML Schema Validation (wikipedia)
Description: XML Schema is basically the same as DTD, but defined in XML (DTD is not XML itself). It's the recommended standard of the W3C and supports recent developments of XML like namespaces (DTD does not). Appart from that, XML Schema is as powerful as DTD.
Syntax:
<xs:element name="Country">
  <xs:simpleType>
    <xs:restriction base="xs:string">
      <xs:enumeration value="FR" />
      <xs:enumeration value="DE" />
      <xs:enumeration value="UK" />
    </xs:restriction>
  </xs:simpleType>
</xs:element>
Usage in Orxonox: An XML Schema (or DTD) could be useful in Orxonox because it allows to define constraints, allowed values, default values, etc. I'm not really interested in the validation itself (I assume we only generate valid XML files anyway, either manually or with an editor), but the XML Schema can be used to create XML files in an external XML editor. Through the XML Schema, the editor can list all allowed elements and attributes. Additionally the definition of default values is very powerful in combination with XPath (see above): If an attribute has a default value, but is not explicitly listed in the XML file, it will not be recognized by XPath. In combination with an XML Schema however XPath would also recognize the (implicit) default values.

XInclude (wikipedia)
Description: Allows inclusion of other files (both XML files and plain text files)
Syntax: <xi:include href="file.xml"/>
Usage in Orxonox: Currently we include files with lua, in future we could do this with XInclude. A few posts above I explained that I want to remove the need for explicit inclusions, so this may be a bit surprising, but that statement was made regarding templates. But we could still include commonly used code like currently the weapon settings. XInclude is superior to lua include because it needs no pre-processing.


Some less important XML features that could still be useful:

XML Base (wikipedia) allows the definition of a "root" path, all other paths (e.g. for XInclude) are then relative to this base.

xml:id defines a unique id for each object (or rather ensures that a given id is unique if present)


More techniques that are probably not useful in Orxonox, but just to give you some insight:

XSLT (wikipedia) is a transformation language which transforms an XML document into another XML document following some rules. We will probably never use this, but one possible case could be to define GUIs in an Orxonox specific XML format and then transform it into CEGUI conformant files.

XPointer (wikipedia) is a technique to address some parts of an XML document. I'm not entirely sure how this differs from XPath, but it's probably used to reference objects in other files. If at some point we know more about whether and how to use XPath in Orxonox, we can probably also tell if XPointer is of any interest to us.

XLink (wikipedia) is used to link from one XML file to another. This is basically the same as links in HTML documents, but generalized for XML. This is probably only interesting if XML is presented to a user in some sort of a browser (like HTML).

XQuery (wikipedia) is basically a query language like SQL but instead of retrieving information from a database it does the same with an XML file. additionally it's a functional programming language.
Fabian 'x3n' Landau, Orxonox developer

User avatar
1337
Baron Vladimir Harkonnen
Posts: 521
Joined: Wed Oct 10, 2007 7:59 am

Re: Enhancement of the XML connection

Post by 1337 » Sat Apr 16, 2011 9:32 pm

Wow, that's quite a summary ;) Thank you a lot for gathering all the information.
Unfortunately I have no contribution to make at all. I agree with your points and I am 100% sure you covered everything around XML :P

Though I would like to emphasize the wish to get rid of preprocessing. It does sound very powerful and tempting, but we can see what happens when looking at C/C++... If there is any way to remove the need to preprocess a file, I would embrace that a lot.
http://www.xkcd.com/
A webcomic of romance, sarcasm, math, and language.

Post Reply

Who is online

Users browsing this forum: No registered users and 10 guests