Where do you get XML file formats from
Looking for questions like Xml or Sqlite when should you remove Xml for a database? and What are some good alternative data formats in XML? it is clear that XML is what you best use to exchange data between systems, organizations, and software products. For internal use, other formats tend to be more compact and scalable, such as plain text forms, regular source code, or database usage.
As soon as it comes time to move data to another program / tool / system / organization in XML: where and how do you define the data format encapsulated in XML file? It's clear that you need strict rules for what happens, and then the value of all the nodes in the tree. XML is not self-documenting, which seems obvious.
Are you using some other design or rolling yourself? Is there any good paperwork guide?
/ Jakob
source to share
Any XML document to be shared with the outside world must have a schema. Using schema gives you an easy and deterministic way to reject XML documents that your process cannot understand.
Because it is deterministic, it also gives people trying to interact with your systems an easy way to know that the XML being generated meets your basic requirements.
You can also use annotation elements in your schema to document business rules that the schema cannot represent. These rules are not automatically applied, of course, but the schema is usually a reasonable place to put them. (It's also easy to write XSLT that outputs human-readable HTML documentation from your annotated schema.)
Development patterns are much easier if you have a good tool. If you write a lot of schemas, XML Spy pays for itself - and XML Spy is shockingly expensive.
I've been doing system integration work for 20 years and XML Schema is a godsend. My rule of thumb is that every diagram I write, even for the simplest interface, eliminates at least two appointments and five phone calls. It also removes a whole class of defects from the finished system.
source to share
How I handle it:
- One element wrapping it all (XML standard)
- One element inside this for each "object".
- Element attributes for each property, if they are of reasonable length.
- The InnerXml text of this element for a property with a lot of text (assuming there is only one)
- Items nested within an item if there are multiple properties with a lot of text.
(sorry, editor just won't let me post XML. Preview and submitted versions don't even match)
If you are writing a sample XML file in VisualStudio, click the toolbar button that will automatically generate an xsd schema for that file. Add "targetNamespace" attribute to XSD and copy it to C:\Program Files\Microsoft Visual Studio 8\Common7\Packages\schemas\xml
(slightly changing VS version).
Then add the xmlns = "{your namespace}" attribute to your root element and VS will pass it the Intellisense for your tags.
source to share
Actually, XML is self-documenting when using DTD or XSD , and this is one of its advantages over text files.
As you might have guessed, using XML to transfer data correctly takes some work. I found the XML tutorial and XSD tutorial at w3schools.com to be helpful. If you go down this road, you may be interested in their textbook on the XSLT .
At first, as Vincent suggests , you can use the existing schema if available. On the other hand, you might find it easier to learn XSD if you create your own (perhaps using an existing one as a starting point).
source to share
You can define structure and data types and constraints for XML documents using XML Schema ( http://www.w3.org/TR/xmlschema-0/ )
It's a good idea to write the correct schema for all the XML documents you use, although sometimes it can be a pain! Otherwise, you have no guarantee that the XML being written out is the same as the XML that another (or the same!) Program expects.
Personally, I find the XML schema makes my head ache, but the principle is good and I would not use the XML format that did not have a proper scema definition if I could avoid it.
source to share
It may depend on what you are trying to imagine. If there is a standard format (i.e. Scheme), then there are advantages to using the standard. So there is musical performance, chemistry, chess, and the list is very long. If you are doing something that is not covered by any existing standards, then your role is yours.
I agree with John that you should always create a schematic. You just don't know how far your application will go.
source to share
Consider using a more specialized form of XML called RDF or Resource Description Framework. RDF models everything as a series of triplets; subject, predicate, object. What you end up with is pretty flat XML with links to descriptor hierarchies of arbitrary depth.
RDF makes heavy use of the spacing between names. The downside to naming the interval is that it makes the XML look a little more busy, so it's a little harder to read by humans. The upside to indicate spacing is that it simplifies your circuit with other circuits by becoming more expandable.
You can use the standard XML to RDF parser, or use one of the many open source libraries that parse RDF and call your SAX style code with this object, predicate, and object.
If that sounds like a good idea to you, this site is a directory of published RDF schemas that you might find useful. Even if you don't find a perfect match, you can find some similar schematics and point out some problems with how you model your own data. Even if you don't go with RDF, it is probably worth spending a little time exploring this site. If you don't find what you want and create your own RDF schema then consider posting on this site.
source to share