ev Aktuell Seminare Reports Homepage Software
printer / text mode version
university-logo
draheim
@informatik.hu-berlin.de

Reports
- postindustr.CC
- XML/Ti Report
- pTA StudienArbeit  .
- sch_llf study
- Geschichte des PC

TechDocs
- Perl Objects
- Installing Oracle
- shell cmds in python
- Using css for xml
    defs   tricks
- Unsafe mono  [x]  !
- Docbook Manpages
- Java Bean   Code
rpm-suse
 
- schema-mappingen
  ig cv hg re dv ev
  zz mk pr
- java problemsen
  lang swing ext gtk jjtree xul
 
boot
-grub-netboot
-grub-gtk
-partclone freshmeat
-partimage links
 
-releaseuploader


sitemap


-guidod-pygtk
sitemap             *offsite link

2004-04-21
(C) Guido Draheim
guidod@gmx.de

 
generated by mksite.sh

schema mapping - evolution

And last not least, we need to look at the way auf automatic generation of schema mappings. There are however quite some areas where automatic generation is impossible or rather inefficient. Here we can make a library of of schema mappings or library of templates and rules to make up good variants from. The actual compiler should choose from the given schema operations, expand templates with concrete parts, and unroll where parts match only via more schema mapping operations. That allows a compiler to regenerate a schema mapping application even if some partial schemas have changed slightly.

The "EVE" model seems to have some good prior work to it - and it has shown us that interaction with wrappers is important just as way to score alternatives. The result should then always be checked for validity to a given output schema of course.

Operations

  • template loading - and expansion
  • scoring of alternatives
  • regenerate - selfcheck on "training set"