Myslim, ze vycet nejrozsirenejsich DTD pro XML by mel byt rozsiren o XML verzi DocBooku (www.docbook.org), ktery se (v XML nebo starsi SGML variante) pouziva pro tvorbu technicke dokumentace na celem svete. Dlouhou dobu je v DocBooku psana i dokumentace k FreeBSD, KDE a migroval na nej z LinuxDoc DTD i Linux.
Dobrý den,
chtěl jsem se jenom zeptat, proč si myslíte, že cituji: "podpora v OpenOffice lepší než třeba v KOffice"? Já si myslím, že _podpora_ je přinejmenším stejná a jde o to, jestli ty dva různé XML formáty budou převoditelné. Vzhledem k tomu, že DTD specifikace souborových formátů KOffice jsou veřejně dostupné (a něco obdobného bych čekal i u OpenOffice), tak zde nevidím žádný problém v přenositelnosti...
Přeju hezký den,
Lukáš Tinkl [lukas@kde.org]
P.S. DTD např. KSpreadu naleznete zde:
http://webcvs.kde.org/cgi-bin/cvsweb.cgi/koffice/kspread/dtd/kspread.dtd
Asi slo o spatnou formulaci. Moje zminka "o tom nejlepsim na konec" mi pravce pripadala schopna vyvolat takovyhle dotaz. Proto jsem tam dal tu vetu, ktera se Vam nelibila, a kterou jsem nechtel K.. a Open.. nijak srovnavat. Slo spis o to, ze OpenOffice, ktery ma za sebou Sun apod. ma daleko vetsi sanci na prosazeni "sveho" XML formatu pro siroke pouziti nez ma treba KOffice - uz jen pro to, ze ho (OpenOffice) lze pouzivat i na Win, coz je pro sirsi rozsireni nezbytne.
Rozhodne jsem nechtel vyvolavat zadne flamy.
S implementaci XML v openffice jsem mel problemy, validovany dokument z docbooku openoffice zatim otevrit neumela, mozna byla chyba u me, ze jsem mel spatne rozhozene styly ale jednoduse to proste neslo.
Jeste bych mel dotaz, kde mozilla bere styly? XML sice nacist jde vzdycky, ale bez jakehokoli formatovani.
Myslím, že tu došlo k určitému nedorozumění. XML se zabývá SYNTAXÍ dat. To znamená, že umožňuje popsat jaké prvky se kde mohou vyskytovat. XML ale vůbec neřeší sémantiku - tedy co dotyčný prvek znamená. Open Office má svůj XML formát dat a DocBook také svůj. Jeden druhému nerozumí (dokáže poznat, že v textu je prvek XY a jeho obsahem je tato část dokumentu, netuší ale zda prvek XY je nadpisem části textu, vloženou tabulkou, položkou do rejstříku nebo třeba telefonním číslem). Význam XML prvkům přiřazuje až aplikace a ta zná jen svůj konkrétní formát.
Dobry den,
snaha firmy Sun na tomto poli je opravdu chvalyhodna. Vize moznosti otvirani
libovolneho dokumentu na libovolne platforme ale vazne na pristupu firmy
M$, ktera opet vyckava, aby potom pripadny standard mohla ignorovat resp.
vytvorit si svuj vlastni (M$ClosedOffice :-) ), samozrejme s neverejnymi
DTD specifikacemi pokud mozno co nejvice nekompatibilnimi s tim, co uz bylo
vytvoreno. Jakakoli dobra myslenka totiz musi byt firmou M$ okopirovana,
upravena tak, aby byla pouzitelna pouze pod produkty firmy M$ a puvodni
projekt musi byt znicen. (viz. Apple, Netscape atd., ale to je spis tema
na jinou diskusi).
Pokud to nepochopi zkostnatela americka justice vcetne jejich
mentalne zaostaleho prezidenta, ktery byl zvolen buhvijakym prapodivnym
zpusobem, a M$ nebude rozdelen, a donucen akceptovat normy, pak se obavam,
ze siroce pouzitelneho formatu se asi nedockame.
Ahoj,
rad bych pridal dalsi aplikaci XML pouzivanou v praxi. Jabber je pomerne novy IM (instant messenger ... neco jako ICQ nebo AIM) vyvyjeny na bazi open source. Pro svoji komunikaci pouziva prave protokolu zalozenem na XML.
(Jenom pro doplneni: Jabber krome jineho podporuje transportni protokoly jinych messangeru, takze pokud vas nebavi, ze nekteri z vasich znamych jsou k dostizeni jen na ICQ a jiny treba jen na Yahoo, poridte si Jabbera a ziskate tim Yahoo, ICQ, AIM, ... v jednom baleni)
http://www.jabbercentral.org , http://www.jabber.org , http://www.jabber.com , http://www.hotjabber.com
Problematice moc nerozumim. Ale podle mne musi kazdy format pro WWW budoucnosti, tedy i XML (ikdyz jde spis o jakysi meta-format) vyresit tyto veci: snadny tisk (dnesni html je pro tisk naprosto nevhodny) - to musi byt umozneno tim, ze budouci format musi podporovat vytvareni a editaci stranek jako stranek tiskovych - s definovanou velikosti, konci stranek, okraji atd.; dale by mel format umoznovat standardni typograficke formatovani (coz html neumoznuje), vcetne rozumne prace s fonty (napr. vlozene fonty atd.). Podminkou je samozrejme vektorova grafika (nejlepsi by byl ovsem postscript), a co se tyce bitmapove grafiky, tak by mel byt pouzivan format nejake "skalovatelne grafiky" - t.j. rozliseni je vydano na pozadani ze serveru http (neco jako treba PhotoCD).
Tisk vám nikdy nevyřeší formát, ale aplikace, která umí provést formátování. To jak vypadá vytištěné HTML z prohlížeče není problém HTML, ale formátovacího engine obsaženého v prohlížečích.
XML není zaměřeno na specifikaci vzhledu dokumentu (na to máme třeba PDF), ale na obsah a strukturu. Formátování je obvykle definováno v odděleném souboru s definicí stylu. Pro XML existuje velice silný stylový jazyk XSL, který umožňuje velice přesně specifikovat formátování dokumentu.
Jinak formát SVG se při bližším ohledání svými principy od PostScriptu moc neliší, odlišná je samozřejmě syntaxe.
Aby se stránky pro Web vytvářely přesně zformátované s přesnou velikostí, je možná snem mnoha ambiciózních grafiků a reklamních agentur, ale je to zcela v rozporu s dnešními trendy - Web se přesouvá na stále širší spektrum koncových zařízení, s dosti odlišnými možnostmi. Nedovedu si představit, jak bych si na mobilním telefonu prohlížel předpověď počasí zalomenou na velikost formátu A4.;)