Denna delen av 99 uppdateras inte längre utan har arkiverats inför framtiden som ett museum.
Här kan du läsa mer om varför.
Mac-nyheter hittar du på Macradion.com och forumet hittar du via Applebubblan.

Går det att importera externt taggade XML-data till FM?

Tråden skapades och har fått 14 svar. Det senaste inlägget skrevs .
1
  • Medlem
  • Stockholm
  • 2011-01-20 16:21

Har ett fånigt problem med inläsning av XML-dokument till filemaker, skapade av en annan databas, där det blir error-meddelande från FM hela tiden.

Tidigare spottade externa Databasen ut .csv - filer och då klarade jag importen med hjälp av ett script som använde ett tillägg från Troi, men nu kommer det en uppdatering och allt ersätts med xml.

Dokumentet ser ut så här:
- OBS! på rad 48 finns ett extraproblem inom fältet med en " (fnutt/citattecken)
- dokumentefternamnet är omdöpt från .xml till .txt för annars kunde jag inte ladda upp det, hit till forumet.

När jag försökte importera innehållet från FileMakers standard XML import, så skickar FM ett felmeddelande - oavsett om "fnutten" på rad 48 tas bort - som jag inte kommer runt.

Innehållet i dokumentets olika tagg-namn måste kunna särskiljas - med informationen per tag-ID / tag-namn, så att de kan bli enskilda poster i olika tabeller.
( t ex varje <player>-taggs innehåll/undertagg motsvarar ett fält, i en post, i en resultat-tabell, samt att <login>-taggen är relationskopplad med ytterligare andra tabeller)

Kanske enkel för den som vet - men jag ser inte den rätta lösningen...
Eller måste man köpa in nya tillägg för att klara biffen?

PS - har FM PRO ADVANCED 10, IFALL DET HAR BETYDELSE

Ursprungligen av 2Lazy:

...så skickar FM ett felmeddelande...

Det kan kanske vara till viss ledning om du berättar vilket felmddelande du får...

  • Medlem
  • Stockholm
  • 2011-01-20 16:42

"XML-tolkningsfel
Unknown element 'tim'
Radnummer: 51
Koloumnnummer: 96 "

- Som jag ser det framgår det indirekt av frågan, att externa XML data inte "fungerar" att importera, när det inte följer FM-standarden och felmeddelandena blir därför lite olika beroende av <taggarna> i dokumentet.

Exporten spottar ur sig en viss typ av XML och FileMaker förstår sig bara på en annan typ av XML.

Det man behöver göra är därför att "översätta" till den typ av XML (eller annat format) som FileMaker vill ha, vilket man enklast och bäst gör med hjälp av XSLT, dvs. en metod som är till just för att göra den typen av transformationer.

Att gå från den generella kunskapen till den specifika är dock ingen barnlek, eftersom det kräver att man förstår sig på hur XSL fungerar, och har du inte själv ägnat dig åt det tidigare så skulle jag föreslå att du anlitar en konsult för det. XSL är visserligen inte omöjligt att lära sig, men om man i övrigt inte har användning av tekniken så står tiden för inlärning inte i proportion till tidsvinsten.

  • Medlem
  • Stockholm
  • 2011-01-21 08:18

Tack för ditt råd, har lyckas att slippa xml programmering eftersom jag sett begränsningar i det inom det nu aktuella området. Men visst kan man köpa sig fri från problemet, men det var inte min tanke.

Det jag undrar är, om det finns något färdigt program/extension som skapar xsl (XSLT) - filen (eller skapar andra förutsättningar för tagginläsning), så att man slipper denna tidskrävande fas.
En annan fråga är om man kan plocka "utvald" tagg till respektive tabell, i så fall, när antalet för <player> varierar? / <player> har 4 child-tags, motsvarande en post med fyra fält.
Antal <player>-tags varierar från fil till fil, de andra <taggarna> har fixerade antal förekomster med samma position.

Viktigaste frågan är om det är rätt väg att gå, ett alternativ är att läsa in hela filen i ett textfält och efterbehandla "inne" i FM, t ex genom något script.

Det vore det trevligt om det finns en "extension" som kan plocka ut taggarna. Jag har tillgång till hela xml-beskrivningen, men jag tror att en van programmerare ser samma sak i bifogade xml-koden.

För att avrunda frågan - måste man gå vägen via xsl-fil för att bäst lösa ett sådan här problem?
- Eller finns det smartare lösningar. Problemet är att det rör sig om ca 50 000 filer om året..., så det måste ske en inläsning med automatik, i slutändan.

Nuvarande .csv - lösning kan "importera" hela filen OM man först tar bort alla "fnuttarna" i dokumentet. I xml-filen gäller de bl a de "fnuttar" som ligger i init-taggen. De gamla .csv filernas innehåll motsvarar bara <player> - taggen, den andra informationen har tillkommit, vilket även kräver nya tabeller, med en relation till övriga delar - den delen har jag kläm på.

Är det någon som har en bra uppfattning eller kunskap om VAD som är bästa metoden för ett sådant här problem? DVS vilken väg är smatast att gå?

  • Oregistrerad
  • 2011-01-21 09:26
Ursprungligen av Richard Rönnbäck:

Exporten spottar ur sig en viss typ av XML och FileMaker förstår sig bara på en annan typ av XML.

Det är iofs inte sant. Filen är ju helt korrekt XML och det finns faktiskt bara en XML standard så om det inte går att importera filen så har ju FM gjort fel och dom borde få smisk.

Däremot så är väl problemet att FM inte vet vad det ska göra med filen. Var ska den stoppa in "Players" exempelvis? Det normala är ju, om du exempelvis importerar en csv fil att du själv anger vilka kolumner som ska tillhöra vilka tabeller - det vore ju bra om samma förfarande gjordes vid en xml import kan man tycka

Ursprungligen av studiox:

Det är iofs inte sant. Filen är ju helt korrekt XML och det finns faktiskt bara en XML standard så om det inte går att importera filen så har ju FM gjort fel och dom borde få smisk.

Däremot så är väl problemet att FM inte vet vad det ska göra med filen. Var ska den stoppa in "Players" exempelvis? Det normala är ju, om du exempelvis importerar en csv fil att du själv anger vilka kolumner som ska tillhöra vilka tabeller - det vore ju bra om samma förfarande gjordes vid en xml import kan man tycka

Filemaker kan bara importera XML-filer som har en viss struktur, det måste finnas speciella XML-taggar. Strukturen i xml-filer varierar kraftigt och bestäms av den som skapar filen För att importera en godtycklig XML-fil måste den godtyckliga XML-filen transformeras till filemakers struktur. När det är gjort med en lämplig xslt väljer man fält att importera på samma sätt som i tab- eller csv- filer.

XSL är för övrigt en helt sjukt bra teknologi, det går att göra saker som andra typer av verktyg är nästintill hopplösa på ett fantastiskt sätt.

Ursprungligen av studiox:

Det är iofs inte sant. Filen är ju helt korrekt XML och det finns faktiskt bara en XML standard så om det inte går att importera filen så har ju FM gjort fel och dom borde få smisk.

Däremot så är väl problemet att FM inte vet vad det ska göra med filen. Var ska den stoppa in "Players" exempelvis? Det normala är ju, om du exempelvis importerar en csv fil att du själv anger vilka kolumner som ska tillhöra vilka tabeller - det vore ju bra om samma förfarande gjordes vid en xml import kan man tycka

XML är en uppsättning syntaktiska regler, men VAD som uttrycks med de reglerna är upp till respektive tillämpning att avgöra. Att säga att det finns bara en typ av XML är lite som att säga att det bara finns ett svenskt alfabete och att därför borde alla som kan alfabetet förstå allt som sägs med dess hjälp.

Det önskemålet som både du och TS har om att kunna välja fält och sedan är det bra med det är på sätt och vis just det problem som XSL löser (eller rättare sagt XPath, som utgör grunden för selektorn). Anledningen till att det är så svårt att bygga gränssnitt för det är för att XML kan uttrycka fabulöst komplicerade strukturer, till skillnad från en typisk csv som normalt sett beskriver fält/kolumn/data på ett väldigt simpelt sätt

Precis som Rolf säger så är de aktuella XML-filerna strukturerade så att de lämpligen skulle ha funnits i olika tabeller i FileMaker

Som Richard säger behöver du transformera XML-filen till ett format som FileMaker kan importera. Detta görs med en XSLT.

Din XML-fil innehåller flera saker som kanske borde varit i flera tabeller i FileMaker, map, settings och players. Jag gjorde en enkelt XSLT för att importera players, du kan ladda ner den här tillsammans med en enkel databas:

Http://www.filemakerbloggen.se/test/raceresults.zip

Importen går att automatisera så att du kan importera flera filer med automatik, schemalagt osv. Är det båtspelet igen?

  • Medlem
  • Stockholm
  • 2011-01-21 09:00

Japp, det är båtspelet, och ditt bidrag med scriptet för att rensa bort $-märknignarna fungerar utmärkt ) .
- Men gud vad segt FM blir när man har över en miljon poster... Det tar tex över en timme att "slänga" allt i alla tabeller...

Det har blivit många "on the fly" - fält i stället - som FM för över uträkningarna till - under natten...

Tusen tack - nu löser sig nog det här också...

Citat:

Tusen tack -nu löser sig nog det här också...

Alldeles säkert :). Det ska mycket till för att det inte ska gå att lösa med filemaker!

Med XSLT går det att importera och exportera till vilka XML-format som helst.

  • Medlem
  • Stockholm
  • 2011-01-21 16:46

Att passera "AHA"-stadiet med så här bra hjälp blev inte så svårt. - stort tack för hjälpen!

När man sätter sig in i XSLT-filens betydelse så var det inte heller så svårt att till slut fatta varför den krävs.

Förvirring uppstår ibland (oftast) när man ska försöka läsa manualen i FM - som i sin tur hänvisar till hjälpmenyn, som i sin tur kan vara lite svårläst och inte alls ge svar på själva grundfrågan.
Det blir inte bättre av FM har en egen skräddarsydd XSLT-standard - gentemot W3C, men det är förmodligen logisk det också...

Men även bautastenen Microsoft har ju krupit till korset avseende att börja följa xhtml & CSS 2.1 standarden - som blivit betydligt bättre i deras senaste web-läsare, så vem vet - kanske FM kryper närmare, den också.

Nu återstår bara frågan, om man som alternativ kan läsa in alla undertaggar inom <result>-taggen på en gång, till ett enda fält - radvis per <player> -, och ändra ordningsföljden på (child)-taggarna (till: rank/time/login/nickname) under <player> och sen även särskilja Child-taggarna med ett kommatecken, allt via en ny omskriven XLST-fil för detta. Då blir informationen identisk med .cvs filens (som sen kan sorteras inom begreppet Kopia/Original - genom tidigare skript för detta)

I så fall kan jag använda alla mina säkerhetsfunktioner och alla skript utan större omskrivning - annars går det ju att göra i en tvåstegsraket - men skillnaden blir mer manuellt arbete och mer tidskrävande med tanke på att det är ca 40 - 50 000 inlästa filer om året...

Om det inte går att lösa med hjälp av en XSLT-fil, direkt vid inläsningen - får ni gärna skrika till - för jag plöjer djupt i manualerna för närvarande.

Nja, bara för att undvika eventuella missförstånd för eventuellt andra läsare av tråden: FileMaker har ingen egen XSLT-standard.

Däremot så är själva grejen med omvandlingar via XSLT att innehållet måste matchas mellan källa och mål (och när man börjar göra komplicerade omvandlingar i viss utsträckning också den XML-parser och den XSLT-processor som används. FileMaker använder sig för övrigt av av Xerxes respektive Xalan, som också används i oerhört många andra programvaror, det är alltså inga egna påhitt från deras sida)

FileMaker följer alltså varenda standard som finns, det är bara en felaktig förväntning att XML skulle vara någon form av standard som gör att alla programvaror som förstår XML också förstår allt som kan uttryckas i XML, och så är det verkligen inte.

  • Medlem
  • Stockholm
  • 2011-01-21 17:30

Oki, VaBra då vet vi mera, och bättre - tack.

Citat:

Nja, bara för att undvika eventuella missförstånd för eventuellt andra läsare av tråden: FileMaker har ingen egen XSLT-standard.

Men under resan upptäcktes en skillnad mellan FM 10 och 11 ( kanske en bug - ref manualen).

<xsl:attribute name="FOUND"> - taggen krävs i 10:an (manualen till trots - ref manualen:-) - men inte i 11:an. När jag tidigare talade om skräddarsydd syftade jag på skillnader...
Men i det du säger om Xerxes respektive Xalan tyder ju i så fall på att "supportuppdateringarna" på 10:an redan upphört, eftersom skillnaden borde ligga i bakomliggande "motorerna". Tråkigt - i så fall...

Får tacka för svaren!
Samtidigt förklarar jag denna tråd för stängd - min följdfråga är utlagd under ny rubrik för att bli tydligare och lättare att hitta på forumet.

Senast redigerat 2011-01-22 18:00
1
Bevaka tråden