docs/wiki/geda-xml_file_formats.html

   1 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
   2  "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
   3 <html>
   4 <head>
   5   <link rel="stylesheet" media="screen" type="text/css" href="./style.css" />
   6   <link rel="stylesheet" media="screen" type="text/css" href="./design.css" />
   7   <link rel="stylesheet" media="print" type="text/css" href="./print.css" />
   8
   9   <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
  10 </head>
  11 <body>
  12
  13 <h1 id="xmlfileformats">XML File Formats</h1>
  14 <div class="level1">
  15
  16 <p>
  17 This page is a starting point for discussions on using XML for commonality between gEDA applications.
  18 </p>
  19
  20 <p>
  21 One major goal of this effort is to provide advanced file format features while still maintaining backward compatibility with the existing file formats (and be able to bring an old design forward with ease if you wish).
  22 </p>
  23
  24 <p>
  25 Another main goal is to start addressing the Symbol Library Hacker task discussed at <a href="geda-todos.html" class="wikilink1" title="geda-todos.html">todos</a>.
  26 </p>
  27
  28 <p>
  29 Yes, this effort is self concious because of <a href="geda-usage.html#can_we_change_geda_to_use_an_xml_file_format" class="wikilink1" title="geda-usage.html">can_we_change_geda_to_use_an_xml_file_format</a>
  30 The concerns expressed there will hopefully be addressed as part of this effort to minimize the impact to existing file formats, and not tie up core developer time on this work.  Specifically issues 2,3,4 and 5 are valid concerns, but they can be overcome with good design and a little bit of coding, especially if this is treated as a wrapper or evolution rather than a totally new file format.
  31 </p>
  32
  33 <p>
  34 While the initial version of the schema has both a large and small format for gschem files, it is assumed that the smaller will progress further to reduce the amount of &quot;file bloat&quot; associated with putting the files in this format.
  35 </p>
  36
  37 <p>
  38 While there are plenty of arguments for and against XML, it does provide one key feature that can be difficult to implement in a custom file format, and that is unification of the different data types each gEDA program expects with minimal impact to the existing programs.  What this schema currently does is separately define gschem file formats and PCB file formats.  The part schema then allows for both of these to be combined into a &quot;part&quot; file without change thus allowing for &quot;heavy&quot; parts containing both symbols and PCB elements.  It will also allow for a project to be stored in a single archive file if the user so chooses.  It thus provides a kind of wrapper functionality that maintains internal structure formats.
  39 </p>
  40
  41 <p>
  42 It also introduces file format validation making sure that the file is well-formed and also, using Schematron, makes sure that constraints on data in the file are checked.  This can be a real plus for managing parts like on gedasymbols.org when files can be &quot;easily&quot; validated for format and content on upload with some perl code.
  43 </p>
  44
  45 <p>
  46 An initial git repository is at http:<em>github.com/oblivian/geda-xml/tree/master
  47
  48 Right now it provides schema for gschem symbol and schematic files, and a PCB file format (adapted from parse.y).
  49 The part/part.xsd schema is for combining the individual schemas into a part format capable of both regular and heavy parts.
  50
  51 convert-symbol.pl (when it is done) will write a gschem symbol to the XML format.
  52 It also performs validation against the XML Schema itself and Schematron rules also stored in the schema files.
  53
  54 The XML Schema for gschem files provides for a &quot;lightweight&quot; file format that should allow for an overlay on the normal file reading routines in libgeda without modification.
  55
  56 So a line in gschem is represented as
  57
  58 &lt;gs:l p=&quot;200 800 200 200 3 0 0 0 -1 -1&quot; /&gt;
  59
  60 instead of
  61
  62 L 200 800 200 200 3 0 0 0 -1 -1
  63
  64 But the validation is handled by the XML parser rather than writing extra validation code.
  65
  66 The XML Schema makes sure the symbols are well-formed, and the Schematron makes sure the data is valid in the &quot;p&quot; attributes.
  67
  68 Work completed:
  69   * XML Schema for gschem, PCB and .xpart file format.
  70 Work that needs to be done to get this effort really started:
  71   * Finish convert-symbol.pl.
  72   * Write XSLT to convert &quot;xpart&quot; file back to .sym/.fp format.
  73
  74
  75
  76
  77 ====== IP-Xact ======
  78 IP-Xact (IEEE-1685] is an industry standard xml schema for packaging and distributing IP and could be adopted by gEDA for internal use as well. Its main advantage is that it uses a component name that is guaranteed to be unique and will never have name collisions with any other IP-Xact components in the world. Each component has a four field identifier called the VLNV ( Vendor name, Library name, Component name and Version) Vendors use a URL that they own for their vendor name and no other IP-Xact file in the world will use that same name.
  79
  80 The vendor name can also be the URL where the IP repository is available for download. Instantiating a VLNV  with github.com, github username and user repo name not only identifies the repository but can automatically download it if it is not already in you local design environment.
  81
  82 IP-Xact allows for the creation of a geda namespace and the addition of any geda specific extensions through the use of &lt;spirit:vendorExtensions&gt;
  83 </p>
  84
  85 </div>
  86 </body>
  87 </html>