Re: Second "RFC" on pkg-data idea for ports

+-------[ Martin ]----------------------
| Am Tue, den 13.04.2004 schrieb Garance A Drosihn um 23:40:
| 
| > Well, do not focus too much on whether it is "XML-like".
| > 
| > It is just a format I dreamed up.  It does what I want it to do.
| > If someone has a better format, and a format which will be as easy
| > for a simple program to process, I will be willing to try that
| > format instead.  I am not too hung up on this specific format.
| 
| I would personally like it to use XML. I'm developing a small
| application which is a kind of GUI for ports (works like a
| browser). It is very difficult to parse the Makefiles to find
| out which version number and which dependencies it has. Some
| versions (like KDE3) are just variables and I don't have an
| idea how to fetch them yet.

The problem then isn't that it's not XML, it's having something well 
defined. Making it bad XML won't make it any better.

XML is not great as a registry/database format. It turns out to be ugly to
parse with code and ugly to edit by humans, and then humans try to to make it
into something else that it isn't. Plus it's so easy to do a bad job in XML.

| With a structured language like XML, it would make the parsing
| process for such utils like mine easier.

Right but harder for shell scripts, or awk, or simple things without every
language needing a validating XML suite installed.

| Furthermore, if you pack more information into the XML-files
| about a port, many things can be automated by using XSLT
| stylesheets (future ideas), like e.g. the Makefiles for the
| ports can be created by a stylesheet. A structured XML file
| is an ideal place for the pkg-descr, distinfo etc.
| You have a centralized resource where you can pick the
| information from you need.

Right and now it's some crazed monster, not just package meta-data. And you
need a specific tool to maintain this data, and all the port maintainers need
to use it on all their platforms.

| I'm not good in XML either, but I would get some more information
| what can be done and if you really want to do it.

What's important then is to; 

o first define exactly what data is going to be stored,
o what it is going to be used for,
o who NEEDS to use it 
o keep it consistent.

People who WANT to use it aren't important right now, if it's easy enough to
use for the people who NEED it, then the WANTers won't have a tough time
building whatever it is they want to build.

| I see. In my opinion, it's generally not a good idea to parse
| XML with custom parsers. Writing out XML to a file is simple.
| XML should be validated during the reading process. In this
| way you can prevent errors and, of course, extend the testing
| process (e.a. make the life easier for some people).

Well this doesn't make sense. If you're using XML is SHOULD be validated when
it's written, because it's probably going to need to conform to a DTD or an
XML-schema. This shouldn't only be detected on read.

The fact you need to validate both the data and the layout of the data should
be a key indicator that this is a heavy-duty process. You need to weigh up
whether or not this cost is worth it.

This is way beyond just checking for simple formatting mistakes.

| > That is what I was thinking of when I picked this specific format.
| > With this strict, limited format, it should be easy to write a
| > program that can do all the processing we want to do (at least
| > for now).
| 
| Before using XML, you should really ask people who have an
| idea about both, ports and XML.

Yeah well, the reasons people give for wanting to use XML, usually turn out to
be the reasons they stop (well they never stop, they just wish they never
started d8). After they have to publish a 60 page document explaining their 
XML schema, which is never up to date with reality... I could go on (and you
know I am)..

Simple is always better. You can build a lot of things with simple building
blocks.

-- 
Totally Holistic Enterprises Internet|                      | Andrew Milton
The Internet (Aust) Pty Ltd          |  M:+61 416 022 411   |
ACN: 082 081 472 ABN: 83 082 081 472 |akm_at_theinternet.com.au| Carpe Daemon