On FOSDEM in the speed talks, I held a speed talk about an XML file for YaST and other repositories. The presentation can be found here: http://en.opensuse.org/XML_File_for_repositories until there is an official place for FOSDEM presentations. This discussion is about the layout of the XML file and also about what SUSE already has in place or is planning, so an easy integration is possible. So any feedback on that is welcome. An extremely basic proof of concept in PHP can be found on http://houghi.org/mirrors/main.php (DON'T USE THE DATA. It is not complete and most likely incorrect) the directory holds all the files and php files are copied as php.txt as well. So what we need is to define what the layout of the XML must be. What must go in it and what not. Any feedback is welcome. Example XML files and php pages for proof of concept can be sent directly to me. So please let all know what your ideas are. What does SUSE already have? How do you see the XML layout? houghi -- Nutze die Zeit. Sie ist das Kostbarste, was wir haben, denn es ist unwiederbringliche Lebenszeit. Leben ist aber mehr als Werk und Arbeit, und das Sein wichtiger als das Tun - Johannes Müller-Elmau
This discussion is about the layout of the XML file and also about what SUSE already has in place or is planning, so an easy integration is possible. So any feedback on that is welcome.
An extremely basic proof of concept in PHP can be found on http://houghi.org/mirrors/main.php (DON'T USE THE DATA. It is not complete and most likely incorrect) the directory holds all the files and php files are copied as php.txt as well.
So what we need is to define what the layout of the XML must be. What must go in it and what not. Any feedback is welcome. Example XML files and php pages for proof of concept can be sent directly to me.
So please let all know what your ideas are. What does SUSE already have? How do you see the XML layout?
houghi
Do not have much time (otherwise is had gone to FOSDEM) but this looks great. Maybe it is a smart idea to make the php-script generate a .sh file that can be downloaded. It is not that hard. Azerion
On Mon, Feb 27, 2006 at 04:21:55PM +0100, houghi wrote:
So please let all know what your ideas are. What does SUSE already have? How do you see the XML layout?
OK. Nobody? Ik have thought up two structures. Please give me some feedback. First structure: Belgium Skynet (ftp.skynet.be) pub/ftp.opensuse.org/opensuse/distribution/ (openSUSE.org mirror) delta-iso 10.0 ftp i386 x86_64 http i386 x86_64 rsync i386 x86_64 10.1 ftp i386 inst-source 10.0 ftp pub/ftp.suse.com/suse (ftp.suse.com mirror) inst-source-extra 10.0 ftp i386 iso 10.0 ftp i386 packman.mirrors.skynet.be/pub/packman/ - 10.0 ftp i386 Second structure: 10.0 i386 delta-iso be skynet ftp.skynet.be pub/ftp.opensuse.org/opensuse/distribution/ ftp http pub/ftp.suse.com/suse ftp http packman.mirrors.skynet.be pub/packman ftp belnet ... de gwdg ... inst-source be ... x86_64 ... 10.1_B5 i386 delta-iso be ... x86_64 ... Wich one would you prefer? Wich one is more logical to you and if none, do you have another proposal? It should be workable from version 10.0 onward and should include additional repositoeries as well. houghi -- Nutze die Zeit. Sie ist das Kostbarste, was wir haben, denn es ist unwiederbringliche Lebenszeit. Leben ist aber mehr als Werk und Arbeit, und das Sein wichtiger als das Tun - Johannes Müller-Elmau
Hey, there is an method for designing databases the best way. Maybe you should take a look at that cause it causes the most efficient way of datahandling. Check this :D Product table: 1 | Cookies | 4$ 2 | Milk | 50ct 3 | Potatoes | 4$ 4 | Cola | 50ct 5 | Water | 50ct 6 | Beer | 50ct As you can see, there is a lot of the same info in it (50ct). So a database like the next one would be better: Product table: 1 | Cookies 2 | Milk 3 | Potatoes 4 | Cola 5 | Water 6 | Beer ProductPrices table: 50ct | 2,4,5,6 4$ | 1,3 I know you do not design a database-structure but maybe it helps a hand anyway. Make sure there is not much 'the same text' in the file. But dont make it unreadable either :D. Maybe trying to style the xml like a ftp-directory is the best way? ======================== be skynet ftp.skynet.be ftp http pub/ftp.opensuse.org/opensuse/distribution/ 10.0 i386 delta-iso inst_source i586 delta-iso inst_source 10.1 i386 delta-iso inst_source i586 delta-iso inst_source packman.mirrors.skynet.be ftp http pub/packman i386 i586 belnet ........... de gwdg ftp etc
On Tue, Feb 28, 2006 at 11:12:13PM +0100, Azerion wrote:
Hey,
there is an method for designing databases the best way. Maybe you should take a look at that cause it causes the most efficient way of datahandling. Check this :D
Product table: 1 | Cookies | 4$ 2 | Milk | 50ct 3 | Potatoes | 4$ 4 | Cola | 50ct 5 | Water | 50ct 6 | Beer | 50ct
As you can see, there is a lot of the same info in it (50ct). So a database like the next one would be better:
Product table: 1 | Cookies 2 | Milk 3 | Potatoes 4 | Cola 5 | Water 6 | Beer
ProductPrices table: 50ct | 2,4,5,6 4$ | 1,3
I know you do not design a database-structure but maybe it helps a hand anyway. Make sure there is not much 'the same text' in the file. But dont make it unreadable either :D. Maybe trying to style the xml like a ftp-directory is the best way?
Again, I have no real experience with XML, so I have no idea how to get to what you are talking about above. houghi -- Nutze die Zeit. Sie ist das Kostbarste, was wir haben, denn es ist unwiederbringliche Lebenszeit. Leben ist aber mehr als Werk und Arbeit, und das Sein wichtiger als das Tun - Johannes Müller-Elmau
Again, I have no real experience with XML, so I have no idea how to get to what you are talking about above.
houghi
I dont have that neither: The key is to prevent double info. Things that don't change have to be in the top of the structure. It is stupid to have a line about the FTP-address every time while it is clear that the skynet-tree -always- uses ftp.skynet.be. This: ============================================ 10.0 ftp ftp.skynet.be /pub/suse/distribution/ i386 i586 10.1 ftp ftp.skynet.be /pub/suse/distribution/ i386 i586 ============================================ Can also be written as: ============================================ ftp.skynet.be ftp /pub/suse/distribution/ 10.0 i386 i586 10.1 i386 i586 ============================================ As you can see, the 2nd does contain the same information but it is more effective. It is still logical if you 'read' the tree, so it is not a hard way to code it this way. (that last one could be ->386 and under that 10.0 and 10.1 but that would make it a lot harder to code/use and then 10.0 and 10.1 would be repeated in i586 and i686 anyway. Choices have to be made, solutions have to be found.) Don't have a lot of time at the moment but will have in a while (1 or 2 weeks). Maybe can design a structure that does the job nicely :D Azerion
On Wed, Mar 01, 2006 at 12:56:09AM +0100, Azerion wrote:
Again, I have no real experience with XML, so I have no idea how to get to what you are talking about above.
houghi
I dont have that neither:
The key is to prevent double info. Things that don't change have to be in the top of the structure. It is stupid to have a line about the FTP-address every time while it is clear that the skynet-tree -always- uses ftp.skynet.be.
This: ============================================ 10.0 ftp ftp.skynet.be /pub/suse/distribution/ i386 i586 10.1 ftp ftp.skynet.be /pub/suse/distribution/ i386 i586 ============================================
Can also be written as:
============================================ ftp.skynet.be ftp /pub/suse/distribution/ 10.0 i386 i586 10.1 i386 i586 ============================================
As you can see, the 2nd does contain the same information but it is more effective. It is still logical if you 'read' the tree, so it is not a hard way to code it this way.
(that last one could be ->386 and under that 10.0 and 10.1 but that would make it a lot harder to code/use and then 10.0 and 10.1 would be repeated in i586 and i686 anyway. Choices have to be made, solutions have to be found.)
Don't have a lot of time at the moment but will have in a while (1 or 2 weeks). Maybe can design a structure that does the job nicely :D
That would be nice. Remember that with what you propose it will be: ftp.skynet.be ftp /pub/suse/distribution/ 10.0 i386 i586 10.1 i386 i586 ftp.skynet.be http /pub/suse/distribution/ 10.0 i386 i586 10.1 i386 i586 ftp.skynet.be rsync /pub/suse/distribution/ 10.0 i386 i586 10.1 i386 i586 ftp.example.org ftp /pub/suse/distribution/ 10.0 i386 i586 10.1 i386 i586 The problem I have with deciding what the best order is, is that a lot of the data is double. houghi -- Nutze die Zeit. Sie ist das Kostbarste, was wir haben, denn es ist unwiederbringliche Lebenszeit. Leben ist aber mehr als Werk und Arbeit, und das Sein wichtiger als das Tun - Johannes Müller-Elmau
That would be nice. Remember that with what you propose it will be:
ftp.skynet.be ftp /pub/suse/distribution/ 10.0 i386 i586 10.1 i386 i586 ftp.skynet.be http /pub/suse/distribution/ 10.0 i386 i586 The problem I have with deciding what the best order is, is that a lot of the data is double.
houghi
That problem will stay that way, because we cannot make the URL-generator too dynamic. We could make an superior xml-sheet with almost no duoble information but that would be a mess to work with or to extend in the future. In my proposal it would be: (I think that an ftp don't have to be http but if it is it will use the same directory) Don't understand the i368 thing yet. I know why it exist but I don't know how to implement that (at 02:55 am) yet. The i386-folder inside the suse-folder contains much more the the ppc-folder does. But if someone uses ppc the genarator has to know what is available and what is not..... Anyway... <de> <gwdg> <address>ftp.gwdg.de</address> <method>ftp,http,rsync</method> <rootfolders> <opensuse> <folder>pub/opensuse/distribution/</folder> <version>10.0<version> <dir>inst_source</dir> <dir>inst-source-java</dir> <version>10.1<version> <dir>inst_source</dir> </opensuse> <suse> <folder>/pub/suse/</folder> <version>10.0<version> <dir>SUSE-Linux10.0-GM-Extra</dir> <dir>inst-source-extra</dir> <version>10.1<version> <dir>inst-source-extra</dir> </suse> <packman> <folder>/pub/linux/packman/suse/</folder> <version>10.0<version> <version>10.1<version> </packman> </rootfolders> </gwdg> <next german server> </next german server> </de> <be> </be> <nl> </nl>
On Wed, Mar 01, 2006 at 02:59:10AM +0100, Azerion wrote:
That problem will stay that way, because we cannot make the URL-generator too dynamic. We could make an superior xml-sheet with almost no duoble information but that would be a mess to work with or to extend in the future. In my proposal it would be:
Expantion is important, especially as I have no idea (yet) how the build-server will be.
(I think that an ftp don't have to be http but if it is it will use the same directory)
Read below
Don't understand the i368 thing yet. I know why it exist but I don't know how to implement that (at 02:55 am) yet. The i386-folder inside the suse-folder contains much more the the ppc-folder does. But if someone uses ppc the genarator has to know what is available and what is not.....
There are sites that have much less and some much more.
Anyway...
<de> <gwdg> <address>ftp.gwdg.de</address> <method>ftp,http,rsync</method>
Well, this is someting I did not know was possible. That creates new opportunities. :-)
<rootfolders> <opensuse> <folder>pub/opensuse/distribution/</folder> <version>10.0<version> <dir>inst_source</dir> <dir>inst-source-java</dir>
We could then use: <dir>inst_source, inst-source-java</dir> or do I make a mistake here? <snip> houghi -- Nutze die Zeit. Sie ist das Kostbarste, was wir haben, denn es ist unwiederbringliche Lebenszeit. Leben ist aber mehr als Werk und Arbeit, und das Sein wichtiger als das Tun - Johannes Müller-Elmau
<de> <gwdg> <address>ftp.gwdg.de</address> <method>ftp,http,rsync</method>
Well, this is someting I did not know was possible. That creates new opportunities. :-)
<rootfolders> <opensuse> <folder>pub/opensuse/distribution/</folder> <version>10.0<version> <dir>inst_source</dir> <dir>inst-source-java</dir>
We could then use: <dir>inst_source, inst-source-java</dir> or do I make a mistake here? <snip>
houghi
I guess that I made some mistakes, but first of all: why do you want to use XML? the <de> and <gwdg> tags are not XML-valid I guess, so they have to be replaced like this (and I think the , can be solved more XML-valid too): <tree> <country>de</country> <name>gwdg</name> <address>ftp.gwdg.de</address> <method> <m>ftp</m> <m>http</m> <m>rsync</m> </method> ...cut.... </tree> <tree> <country>be</country> <name>skynet</name> ... </tree> Too be honest...i'm fugged up now and can't think that well. Messing it all up :). Give me a few days and I will present a nice structure that is XML-valid . Azerion
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Azerion wrote:
<de> <gwdg> <address>ftp.gwdg.de</address> <method>ftp,http,rsync</method> Well, this is someting I did not know was possible. That creates new opportunities. :-)
It's not, that's a horrible way to use XML :S Furthermore, some servers have the same URL for ftp and http, but some don't. Now if you're going to have 20 different ways of specifying protocols, server names and URLs, you can stop the whole thing right now, it's going to be - - unmaintainable - - useless for automated processing by scripts and applications - - a nightmare to transform to HTML, PHP, text, ...
<rootfolders> <opensuse> <folder>pub/opensuse/distribution/</folder> <version>10.0<version> <dir>inst_source</dir> <dir>inst-source-java</dir>
We could then use: <dir>inst_source, inst-source-java</dir> or do I make a mistake here?
Yes: never, ever, use separators like "," for a list of values like above. Rather do something like this: <directories> <dir>inst-source</dir> <dir>inst-source-java</dir> </directories>
I guess that I made some mistakes, but first of all: why do you want to use XML?
1) validation of grammar, using a DTD and/or an XML Schema 2) very easy to parse by scripts and applications, for processing (e.g. to validate the URLs by making HTTP HEAD requests and such) 3) to transform it into various formats, using XSLT: - HTML/XHTML: a static page with all the data and links - plain text - PHP source file: as PHP objects or arrays to make a dynamic frontend to choose a mirror ...
the <de> and <gwdg> tags are not XML-valid I guess, so they have to be replaced like this (and I think the , can be solved more XML-valid too):
Indeed, <de> and <gwdg> tags are.. well.. they're valid XML but they will never be valid against our schema (and they're very complex to parse) ;-) And that's not how XML is supposed to be used.
<tree> <country>de</country> <name>gwdg</name> <address>ftp.gwdg.de</address> <method> <m>ftp</m> <m>http</m> <m>rsync</m> </method> ...cut.... </tree>
<tree> <country>be</country> <name>skynet</name> ... </tree>
Yes, that's more like it :) To simplify the syntax, better use attributes as well: <mirrors> <mirror country="de" id="gwdg" description="Gesellschaft für ..."> <admin name="Eberhard Moenkeberg" email="emoenke@gwdg.de" /> <baseurl protocol="http" hostname="ftp.gwdg.de" directory="http://ftp.gwdg.de/pub/opensuse/distribution/" /> <baseurl protocol="ftp" hostname="ftp.gwdg.de" directory="http://ftp.gwdg.de/pub/opensuse/distribution/" /> <dist version="10.0" subdir="SL-10.0-OSS"> <repo type="core" subdir="inst-source"> <arch name="i386"/> <arch name="ppc"/> <arch name="x86_64"/> <meta type="yast2" /> <meta type="rpm-md" /> </repo> <repo type="java" subdir="inst-source-java" /> <iso type="cd" subdir="iso"> <arch name="i386" /> <arch name="ppc" /> <arch name="x86_64" /> <meta type="yast2" /> <meta type="rpm-md" /> </iso> </dist> <boot-iso subdir="inst-source/boot"> <arch name="i386" file="boot.iso" /> <arch name="x86_64" file="boot.iso" /> <arch name="ppc" file="boot.ppc.iso" /> </boot-iso> </mirror> ... </mirrors> While it is very verbose and a lot of typing, - - we could write a tool that does automatic exploration of URLs and that generates the XML for a mirror - - it has to remain flexible and extensible, because a) some servers might have directory structures of their own b) who knows how 10.2, 10.3, 11.0 will be structured ;) Also keep in mind the various pages we could generate from the same XML source: - - a static HTML page by country - - static HTML pages by repository type (rpm-md, yast2, ...) - - smart channel files or yum repository files - - dynamic HTML through e.g. PHP where you choose your architecture first, then your country, etc... - - a static HTML page for downloading the network installation boot.iso etc...
Too be honest...i'm fugged up now and can't think that well. Messing it all up :). Give me a few days and I will present a nice structure that is XML-valid .
I also started writing an XML Schema for it, with a sample file, but it's far from finished. I'll post what I've got later on. First of all, we really have to decide about - - what data we need - - how to structure that data, also in a way it suits XSL transformations best - - and finally the XML grammar (XML Schema or DTD) cheers - -- -o) Pascal Bleser http://linux01.gwdg.de/~pbleser/ /\\ <pascal.bleser@skynet.be> <guru@unixtech.be> _\_v The more things change, the more they stay insane. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFEBVVWr3NMWliFcXcRAskBAJ9jWfVrmnYRjty06mRdcZB1szHSSACeKlkx YGbbzQMQpkYoILbwrZu0Mys= =0D+r -----END PGP SIGNATURE-----
On Wed, Mar 01, 2006 at 09:03:34AM +0100, Pascal Bleser wrote: <snip a lot of stuff I completely agree with> That is what I was thinking about.
I also started writing an XML Schema for it, with a sample file, but it's far from finished. I'll post what I've got later on.
First of all, we really have to decide about - - what data we need - - how to structure that data, also in a way it suits XSL transformations best - - and finally the XML grammar (XML Schema or DTD)
These are indeed the questions that need to be answerd first, so we don't have to correct things later. So what data do we need? Also into what detail do we want to go? In your example the boot.iso is onto file level. Interesting for the ISOs, but most likely not realy needed for individual files. Things that need to be included are apart from the abvious parts that will bring up the URL in the end are decription, an ID , the country and such. Also klet us not forget that download.opensuse.org will be doing the exact same thing most likely automatically for you, so if you point to download.opensuse.org it should already know a lot of things. (Small) disadvatage is that with download.openSUSE.org you can not decide yourself what mirror you want to use. So let us not forget the external additional repositories, like Guru or Packman wich might also have mirrors for themselves. houghi -- Nutze die Zeit. Sie ist das Kostbarste, was wir haben, denn es ist unwiederbringliche Lebenszeit. Leben ist aber mehr als Werk und Arbeit, und das Sein wichtiger als das Tun - Johannes Müller-Elmau
On 1 Mar 2006 at 3:30, houghi wrote:
On Wed, Mar 01, 2006 at 02:59:10AM +0100, Azerion wrote:
[...]
<de> <gwdg>
NO!!! By no means: "NEVER use VALUES as NAMES of elements!" The proper use would be something like <country>DE</country> or <country isocode="de"> (likewise for location|inmstitution|hostname)
<address>ftp.gwdg.de</address> <method>ftp,http,rsync</method>
Please learn XML first: use <method>ftp</method> <method>next method</method>... or <protocol name="ftp" /><protocol name="http" /> [...] Regards, Ulrich
Hi, On Wed, 1 Mar 2006, Azerion wrote:
Anyway...
<de> <gwdg> <address>ftp.gwdg.de</address> <method>ftp,http,rsync</method> <rootfolders> <opensuse> <folder>pub/opensuse/distribution/</folder> <version>10.0<version> <dir>inst_source</dir> <dir>inst-source-java</dir> <version>10.1<version> <dir>inst_source</dir> </opensuse>
One path step missing or incorrect: SL-10.0-OSS.
<suse> <folder>/pub/suse/</folder> <version>10.0<version> <dir>SUSE-Linux10.0-GM-Extra</dir> <dir>inst-source-extra</dir> <version>10.1<version> <dir>inst-source-extra</dir> </suse>
It is /pub/suse/i386/10.0/inst-source-extra.
<packman> <folder>/pub/linux/packman/suse/</folder> <version>10.0<version> <version>10.1<version> </packman>
</rootfolders> </gwdg>
<next german server> </next german server> </de> <be> </be> <nl> </nl>
Cheers -e -- Eberhard Moenkeberg (emoenke@gwdg.de, em@kki.org)
On 1 Mar 2006 at 0:25, houghi wrote:
Again, I have no real experience with XML, so I have no idea how to get to what you are talking about above.
The PLEASE, visit http://www.w3c.org/ and learn XML before you design!!! Regards, Ulrich
On Wed, Mar 01, 2006 at 08:57:25AM +0100, Ulrich Windl wrote:
On 1 Mar 2006 at 0:25, houghi wrote:
Again, I have no real experience with XML, so I have no idea how to get to what you are talking about above.
The PLEASE, visit http://www.w3c.org/ and learn XML before you design!!!
If I would do that, this whole process will come to a standstill. I have looked into XML and could not figure it out. That is the reason I asked people with a lot more insight and experience. houghi -- Nutze die Zeit. Sie ist das Kostbarste, was wir haben, denn es ist unwiederbringliche Lebenszeit. Leben ist aber mehr als Werk und Arbeit, und das Sein wichtiger als das Tun - Johannes Müller-Elmau
Op woensdag 1 maart 2006 10:45, schreef houghi:
On Wed, Mar 01, 2006 at 08:57:25AM +0100, Ulrich Windl wrote:
On 1 Mar 2006 at 0:25, houghi wrote:
Again, I have no real experience with XML, so I have no idea how to get to what you are talking about above.
The PLEASE, visit http://www.w3c.org/ and learn XML before you design!!!
If I would do that, this whole process will come to a standstill. I have looked into XML and could not figure it out. That is the reason I asked people with a lot more insight and experience.
houghi
And I only wanted to show that using a good structure probably will decrease the amount of double info. I have exams so I don't sleep a lot and @ 2:00am it all went wrong (so the replies about <de> are alleready outdated cause I fixed it within an hour ;-) ) But hey, the topic was almost closed and LOOK, there are some experts that can help houghi! I will back off (cause I don't know shit about XML :P, but there are enough guys that houghi can contact cause they showed that they have experience........) Azerion
On Wed, Mar 01, 2006 at 02:11:31PM +0100, Azerion wrote:
But hey, the topic was almost closed and LOOK, there are some experts that can help houghi! I will back off (cause I don't know shit about XML :P, but there are enough guys that houghi can contact cause they showed that they have experience........)
And I thank you for keeping the subject alive. houghi -- Nutze die Zeit. Sie ist das Kostbarste, was wir haben, denn es ist unwiederbringliche Lebenszeit. Leben ist aber mehr als Werk und Arbeit, und das Sein wichtiger als das Tun - Johannes Müller-Elmau
Op woensdag 1 maart 2006 15:23, schreef houghi:
On Wed, Mar 01, 2006 at 02:11:31PM +0100, Azerion wrote:
But hey, the topic was almost closed and LOOK, there are some experts that can help houghi! I will back off (cause I don't know shit about XML :P, but there are enough guys that houghi can contact cause they showed that they have experience........)
And I thank you for keeping the subject alive.
houghi
No problem. It was/is a shame that it was dying cause the idea is so good.
Hi, it's very fancy to talk about XML, but please: Whenever you talk about XML, also talk about DTDs. Without a DTD, XML is not more than "every element that starts also has to end, and you may nest elements". May that's why most peaply are so excited by XML: They just wrap something in XML. A DTD is absolutely essential for verifying XML files (other than low-level syntax). So provide a DTD, and also make sure that the XML files you create or use conform to that DTD. Regards, Ulrich On 27 Feb 2006 at 16:21, houghi wrote:
On FOSDEM in the speed talks, I held a speed talk about an XML file for YaST and other repositories. The presentation can be found here: http://en.opensuse.org/XML_File_for_repositories until there is an official place for FOSDEM presentations.
This discussion is about the layout of the XML file and also about what SUSE already has in place or is planning, so an easy integration is possible. So any feedback on that is welcome.
An extremely basic proof of concept in PHP can be found on http://houghi.org/mirrors/main.php (DON'T USE THE DATA. It is not complete and most likely incorrect) the directory holds all the files and php files are copied as php.txt as well.
So what we need is to define what the layout of the XML must be. What must go in it and what not. Any feedback is welcome. Example XML files and php pages for proof of concept can be sent directly to me.
So please let all know what your ideas are. What does SUSE already have? How do you see the XML layout?
houghi -- Nutze die Zeit. Sie ist das Kostbarste, was wir haben, denn es ist unwiederbringliche Lebenszeit. Leben ist aber mehr als Werk und Arbeit, und das Sein wichtiger als das Tun - Johannes Müller-Elmau
--------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-factory-unsubscribe@opensuse.org For additional commands, e-mail: opensuse-factory-help@opensuse.org
Op woensdag 1 maart 2006 08:30, schreef Ulrich Windl:
Hi,
it's very fancy to talk about XML, but please: Whenever you talk about XML, also talk about DTDs.
Without a DTD, XML is not more than "every element that starts also has to end, and you may nest elements". May that's why most peaply are so excited by XML: They just wrap something in XML.
A DTD is absolutely essential for verifying XML files (other than low-level syntax). So provide a DTD, and also make sure that the XML files you create or use conform to that DTD.
Regards, Ulrich
Sounds like we finally have found an expert :D. Show us the way! Azerion
On 1 Mar 2006 at 8:33, Azerion wrote: [...]
Sounds like we finally have found an expert :D. Show us the way!
As someone (you?) already pointed out: It's very much like database design (or "knowledge engineering", whatever you like more). You have entities (in the database sense) and relations between entities. In XML you would map database entities to "elements", and you'd map database relations in to references (like HTML's "<a href=id>" and "<a name=id>"). Database "tables" would be sequences of elements in XML. That's basically it. The DTD (Document Type Definition) defines what elements are known, what their attributes are, and how they may be nested. The DTD has its own syntax. Finally: I'm no XML expert, because I think SGML is powerful enough ;-) Recommended reading: http://www.w3.org/TR/REC-xml Regards, Ulrich
participants (5)
-
Azerion -
Eberhard Moenkeberg -
houghi -
Pascal Bleser -
Ulrich Windl