Sign in to follow this  
Guest GerrishGray

Correct XML syntax

Recommended Posts

Hi guysLots of the posts about BGLComp are about trouble with the syntax of the XML code. The biggest problem is understanding 'empty' elements, it seems.A normal element that can contain sub-elements always has the syntax < ... sub-elements ... >Note that one of things that an element can contain is plain text, not enclosed in any <> tag brackets. ThusHere is some textis legal ('well-formed') XML - although this form has no particular use in XML source code for BGLComp.An element that has been defined in the schema as being an 'empty element' (i.e. one that cannot contain sub-elements), however, is normally written with the 'shortcut' syntaxi.e. as a single tag terminated with '/>' instead of the usual '>'You can also legally use the syntaxBUT, and this is where people have been going wrong, there must be NO 'whitespace' (spaces, tabs, linefeeds, etc) between the '>' that terminates the opening tag and the '' that commences the closing tag. This is because any such whitespace would be regarded by the XML parser as some plain text contained in the element ... which isn't allowed for 'empty' elements.(Note that whitespace is fine everywhere else - it is just in this one particular instance that it is a big no-no).So there is no fault or special consideration for the BGLComp XML schema, this rule is just basic XML.Why bother to use the longer syntax for these elements when the shortcut form is available anyway? Just extra typing (and an opportunity for making an error) for no purpose.Hope this helps everyone understand.By the way, XML code is easier to create/edit with a proper XML editor. Here are a couple of fairly good free ones that I know of, for those who don't already have the MS equivalent from Visual Studio:- Peter's XML Editor from http://www.iol.ie/~pxe/download.html- XMLProEdit from http://www.daveswebsite.com/software/xmled...0/default.shtmlbut neither can actually check the validity of your code against the schema at present.But for those who don't mind shelling out $50 for the 'home' version, best is the incomparable XMLSpy from http://link.altova.comYou can get a 30-day evaluation licence for free in the first instance. XMLSpy DOES validate your code against the schema, and will enable you to write code for BGLComp using a 'pick-and-click' interface for the syntax, so you are virtually guaranteed success every time (once MS have managed to issue a schema that actually matches their BGLComp compiler, of course ... :-0).CheersGerrish

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

Hi Gerrish.There is a reason for the two different formats.From the SDK:Some scenery elements are not allowed to contain other sub-elements. The form of the XML is used to distinguish between these types of elements. Elements allowed to have sub-elements take this form:

Share this post


Link to post
Share on other sites

With the greatest of respect, Dick, I think you are missing the point. The strict syntax for empty elements is nothing to do with a decision by MS for BGLComp, it is inherent to XML.As regards your reaction to the use of XML source code, I cannot agree. XML is rapidly becoming THE standard and it has all sorts of advantages, not least of which is its clear structure. It is easy to learn, and with the benefit of a top-notch XML editor like XMLSpy, it makes the task of writing and validating code infinitely easier. The strictness of the syntax is a major advantage that will hopefully avoid all the wooliness and confusion we had in the past.There is also absolutely no reason, or evidence, to think that MS intend to have FS interpreting raw XML source code in the future. That would indeed be a daft, backward, move when an external compiler can do the job. We have a new BGL format that is a clear indication of the route being followed - I can't imagine that MS have invested the last two years (plus ?) in its development just to abandon it again and take a different route.OK, so there are a couple of small mistakes in the initial release of the SDK, schema and examples. No big deal, it's not ALL wrong! Usually it's the commercial pressures of committed release dates that causes this type of thing, but this time around I suspect it is nothing more than MS playing Santa Claus and pushing it out without sufficient testing to give us something to play with over Christmas.Why on earth do we have to keep knocking the guys who give us this wonderful hobby? At the end of the day they are only human like you and me ... and I don't know about you but I often make mistakes or just plain get things wrong, especially at work when subject to commercial and time pressures.Sorry for the rant, I don't mean to offend you, but I do get a bit sick of all the carping about the hobby I love.CheersGerrish

Share this post


Link to post
Share on other sites

Hi Gerrish.No offense taken.Perhaps I have have missed the point, but I do have one thing to suggest:Show us code examples that work..As far as an interpreted XML? CFS3. In FS9, default.xml in the Autogen folder.Dick

Share this post


Link to post
Share on other sites

Hi DickActually I'm going to do my best to take you up on your suggestion ... I'm compiling an HTML Help file to 'enhance' (or whatever you like to call it!) the SDK doc. It will take me a little while amongst other tasks I have at the moment, so don't hold your breath! But I am avidly monitoring this forum in the process to get as much info as possible, so your posts really are much appreciated, and ALL help and suggestions are welcome. As soon as I have a worthwhile document with some flesh on its bones, I'll get it published and then we can hopefully all use it as a sort of 'knowledge base' in which to accumulate the sum of our findings.You're quite right about CFS3. It's now a totally separate product line from FS, handled by separate developers, and they have indeed taken some seriously wrong directions, which is why most of us have just given up on it altogether. But I doubt that the FS team are going to be so stupid!!! As regards the XML file for the Autogen object configuration, it is simply an alternative for what formerly would have been a .cfg file, and is much easier to control and parse in XML format. Like the other .cfg files, it is read during the FS boot process and its data transferred to internal tables, not used as a 'scenery file' while the sim is running.CheersGerrish

Share this post


Link to post
Share on other sites

Hi Gerrish.The help file will be much appreciated by everyone!I guess I wouldn't be as delicate as to say it's to 'enhance", but rather to 'correct'. There is something in your mentioning bashing MS' efforts to give us information... and I'm guilty as charged. In truth, I'm much relieved to get the info, but a little frustrated about errors in both the documentation, and the XSD file.I do disagree with you about the direction of the design team going towards XML. I see it as a wrong direction, and I do think it is a step towards an interpreted usage in the future.It removes us a step from the actual code used in the sim. That gives MS greater flexibility to change the machine code, but restricts what we can do with the scenery engine. For example, we had found a nice usage for zero-height generic buildings at elevation for helipads... works like a charm. But that code is not allowed in the FS9 XML code. The compiler prevents it, although I suspect the engine is fine.Dick

Share this post


Link to post
Share on other sites

Hi Gerrish, DickJust to join the fray :)About xml: I think that in the long run MS will scrap the binary code, dump the compiler and go with xml source files. If done right, I actually welcome this step. Newer games seem to leave binary files behind and being able to modify a game just with a text editor is a tempting idea indeed. Computers can handle this sort of thing now, as other recent games show. The only worry I have is the total file size, but hard drives are getting bigger and bigger (and dvds are slowly taking over).I'm not in love with xml, personally, I prefer a more C like syntax, like used in the Quake/Doom series. But after all, it is a standard that looks like it's going to stick around for a while. I guess we all have to bite the bullet and get used to it (I have even used xml for my landscape viz research, oh horror, oh horror).I never owned the CFS3 "desaster", so I can't comment. From all that I read, this is a fine example on how to NOT do it. But I wouldn't blame xml for it, just how it was handled by the game itself. And I'm convinced it could be done much better.About the mistakes:I'm with Dick here all the way, sorry Gerrish. Yes, I accept that the MS guys are human and make mistakes. But so far, every single SDK seems to be spiked with mistakes, errors, ommissions. The problem is that there is a sloppiness in the team and they just don't care. My point is that other game developers get their act together. "Game packs/sdks" from other developpers are of much, much, much higher quality then what MS releases. The mistakes in the bglcomp SDK aren't really that bad for someone like me, because I can figure them out pretty quickly. Still, it DOES waste innecessary time. And less computer literate people struggle (we had quite a few posts now from people having problems, just because the examples don't compile as given). MS just has to pull themselves together and start releasing SDKs of higher quality (something that is more of an industry standard and not significantly below it). As long as we let them get away with it, nothing is going to change. Also, if MS would start a more interactive relationship with their customers, I'm sure flaws in the SDKs can be forgiven much more easily.Just my 2 cents (no offense meant of course) :)Cheers, Christian

Share this post


Link to post
Share on other sites

By the way, I'm nearly there with having XEmacs verify XML against the schema, too, so if you want a free verifying editor that might be an option (although many people find emacs' leaning curve a bit steep...)http://www.xemacs.org/And a small (tested, working) example (Navaids for NZCH... don't use this, it's for addon scenery):

Share this post


Link to post
Share on other sites

Gerrish... I really thank you for the addresses to the programs as I was just thinking that it would be nice to have a program to just plug these things into.... But...How can I just plug the Samples and the objects into these programs?This would be a really big help.Joe W.

Share this post


Link to post
Share on other sites

I'm not familiar with XML at all, but years ago I studied SGML and mark-up languages for the domain of mixed text and graphics documents (also applicable to multi-media) and could see that it was analogous to SQL for databases. At the time HTML was in its infancy, and drifted away from the principles of SGML. I'm hopeful that XML is being correctly implemented to provide the theoretical benefits of SGML. If so I think it can be beneficial to the flight sim community as an instance of a bigger data management problem domain.scott s..

Share this post


Link to post
Share on other sites

Hi guysA couple of points about the use of XML:1. Having the schema takes a lot of ambiguity out of the syntax: if the documentation is wooly, you can just refer to the schema, or as has already been pointed out, use a tool such as XMLSpy to make sure you get it right.2. Anyone with MS Dev Studio should try double-clicking the schema - it will load up into Dev Studio as a graphic tree structure showing exactly what goes where. There may well be other tools that do this.3. If you don't have a dedicated XML editor (yet!), you can get a quick color-syntax view of an XML file by opening it with Internet Explorer. Many of the better text editors have color-syntax highlighting for XML (and releated) files anyway, so you may find you don't need a dedicated XML editor.4. Microsoft could have used XSL to automatically generate some of the documentation from the scheme, and thus guaranteed the veracity of the documentation (once the minor problems with the schema had been sorted of course). They didn't (obviously).5. A great advantage of XML is that you only have to learn it once, then you can use it in a whole variety of situations (unlike previous code which was specific to FS).6. Compiled vs interpreted: There's no performance penalty in parsing a configuration file on startup (only an insignificantly longer startup time). For this reason, and the sheer convenience of being able to edit a configuration file as text, it makes a lot of sense leaving such files as XML.7. Christian may be right that in future, FS (in flight) will run direct off XML files rather than compiled binaries, but at the moment I suspect there would be too much of a performance penalty. Compiling to binary is a very sensible and probably necessary optimisation with current harware/software capabilities.8. You can do a lot of clever stuff with XML if you start adding XSL templates and scripting (at compile time only - don't get too excited). I've no idea right now what possibilities that might open up, but it might be worth people ehecking the excellent XML (and related technologies) documentation on MSDN. A good place to start may be to do a Google search on MSDN XML Tutorial and follow the top link.9. XML is at least partly self-documenting, a fact that was brought home to me when someone earlier today showed me an old and new version of an exclude. The old version had nothing to indicate the correct order of the parameters (and I bet a few people reading this have got this wrong at least once in the past), nothing to say what the parameters were, and nothing to indicate the correct syntax of the values.That's all for now - just a semi-random set of points as they occurred to me. Apologies if I've inadvertently repeated anything anyone else has said. If anyone has any XML related questions, fire away and I'll try my best to answer them if I'm around.John FarrieVisual Flight http://www.visualflight.co.uk

Share this post


Link to post
Share on other sites

One more point: You can possibly find a full version of XMLSpy on a magazine cover disk - it appears quite regularly. Not the latest version, but useful and useable anyway. I saw one in the UK about a month ago - can't remember which magazine, but it may still be on the shelves.John FarrieVisual Flighthttp://www.visualflight.co.uk

Share this post


Link to post
Share on other sites

>>About xml: I think that in the long run MS will scrap the>binary code, dump the compiler and go with xml source files.>If done right, I actually welcome this step. Newer games seem>to leave binary files behind and being able to modify a game>just with a text editor is a tempting idea indeed. Will this make the scenery "open source"? For example, if the scenery will be distributed as XML source files, wouldn't anyone be able to edit it and redistribute it? On the face of it, it might not seem like a bad idea, but I don't really want to see 10 versions of KLAX. We already see this a little bit with the AFCAD2 files that are uploaded with "competing" versions of airports.I have to admit, I was a bit overwhelmed with the SDK at first, but as I read everyone's posts, my eyes are starting to open. There are a few threads running which show a good exchange of ideas, I think.- Martin

Share this post


Link to post
Share on other sites

I'm afraid I can't remember which magazine it was, though if I had to hazard a guess I'd go for one of the internet/web development titles. Certainly if I spot it I'll let you know.John FarrieVisual Flighthttp://www.visualflight.co.uk

Share this post


Link to post
Share on other sites

Hi JohnThanks for the input and support in trying to convince everyone that MS's choice OF XML makes sense. I see no point in speculating about a future version of FS using XML files direct because we have just been given a new binary version and its not going to be replaced again one version down the road. No version of BGL has ever been truly compiled, of course, all we really get is p-code tokens thatt are still being interpreted at runtime, not executed directly. But what MS have been doing for some time now is to move away from the old concept of a high level interpreter that did all sorts of repetitive work, like triangulation, for us, to a much lower-level system where the p-code is closer to the final instructions and data needed for execution, with much faster execution speeds as a result.By the way, Dick mentioned an intermediate code that can be viewed/logged by using the /V parameter. This is not actually a separate intermediate pseudocode - it is just the first stage output of the XML parser and is still basically the same stuff as the original XML source. We will definitely be needing some XSL stuff to replace the compile time facilities in SCASM for user variables, calculations, etc - I doubt that Manfred will rewrite SCASM for the new BGL format because he has expressed his dislike of XML in the first place. But then again, I suppose he doesn't have to get involved in XML because he would be compiling direct to the new RIFF format and could keep the general syntax of SCASM substantially intact ...But until we get the MakeMDL SDK as well we can't really come to any overall conclusions about the changes.(Sorry about the lack of input from me for past 48hrs guys - I was away in London on business. Home for Xmas now so I'll try to get some work done on the BGLComp documentation ...)CheersGerrish

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this