Format for the future LFS

[George Makrydakis]

On Wednesday 05 March 2008 07:52:19 Alexander E. Patrakov wrote:
> [snip]
> 3) How (from what form of sources) should all of this stuff be generated?

One option then:

There should be a variably verbose XML - based format describing everything 
from different languages for the end user (internationalization is a feature 
I do not see quite often raised here though), different package manager 
selection (if in the end you decide to support multiple versions, which is 
one thing to consider), package metadata information.

As J. Greenlees suggested on this thread, it is advisable to have your own 
DTD, or a set of DTDs about this. Docbook will just _not_ cut it, and it was 
a *BAD* technical decision that leads the team here. I am not 
suggesting "bad" as non functional, but "bad" as in dead - end leading  due 
to not having these options. There are also issues on not just the format of 
the DTD and its "layout" though, or the CSS/XHTML combinations for viewing 
things right; before touching them though, it is better to focus on XML 
itself and one simple thing:

How verbose should it be, and should you "chain" it to the needs of a 
particular package manager?

XML in general, suits the task because of its descriptive power, its almost 
immediate human - readability, its by default modular nature and its 
transfer - medium qualities even between different applications, in a 
standard and predictable by all editors manner. You could for example have 
different XML files describing alternative components to consider during the 
build of a particular "stream" of the book, done by different teams of people 
with talents that can group together nicely targeting a single sector of 
their choice.

There can be quite diverse processing over these in order to produce the 
end "monolithic" XML/package from which everything else stems for that 
package; and you will also need to focus on the tools you want to have for 
something like this.

It should be the XML document format to be the logical supergroup from which 
the eventual PM be "fed" the info from and not the other way around.

Regardless of what you choose to do in the end, there are some extra issues:

1) the freedom you wish to have over the framework for the build cycle.
2) the choice you make on how to maintain the framework for automation.
3) how to prioritize different components so that this does not blow up on 
your face
4) accept the fact that in this way, you need something extremely accurate 
because increased variables in the game mean _increased_ eventual bugs that 
have nothing to do with the sum of the packages as distinct software entities 
over the project.
5) you need steady - rate development. Steady - rate.

By the time you reach (5) there is also going to be a (10). But it will be at 
most 10. And everything should be easy to maintain.

My only concern over this is that if you only wish to go around the pedantic 
route, then this is an overkill. If you don't, then it is a viable 
alternative with even bigger long term potential than what it seems right 
now.

> --
> Alexander E. Patrakov

George Makrydakis