preliminary attempt at one DTD

Jason Gurtz jason at
Thu Jun 21 10:08:10 PDT 2001

> I'm going to have to take a look at this also.  Is alfs going to
> be team or contribution based (or other)?  I've got the itch to
> do some serious programming and design work with a group of guys
> who Have It Together (TM) and I figure that now's my chance.  I
> would hate to see a bunch of people start working on the same
> thing and end up with incompatible design/code though.

Don't know if that has been really discussed at all, but I'd say team based
may be best to avoid the incompatable code issues.  Communication is key to
achieving this.

> >   Perhaps my first contribution could be to create a task tracking
> >   list/database.
> I think this would be a very good idea.  Perhaps we can implement
> the idea of checking out and turning in tasks (in the library
> sense, not the CVS sense) complete with late fees!

AFAIK, Gerard is hard at work trying to weasle bugzilla into working for us.
It's a tough system to implement from what I've heard, so don't know how
much progress has been made there.  Is this the type of thing you where
thinking of?

> Anyway, I'm going to go clean up some more things with the
> initial DTD I wrote and try to start on a system profile DTD.

I started last night on the new syntax documentation for the packages (check
it out if you like )
While we where hashing out some details in #alfs it occured to me to try and
visualize what we are working towards.  What I envision is eventually each
seperate package having its own profile and the system profile using those
to make a compleate system or compleate add on.  So then we whould have:

system.dtd = what you submited the other day
package.dtd = still needs to be done
system.xml = profile for a whole system
package.xml = what is described in sytax.txt

So basicly the frontend will look at the system profile to see what is
wanted, then it will grab all the little profiles it needs.  As long as the
version of a package is known, the dependency info can be looked up in an
external DB.  Else, each package profile whould have to have all dep's in
it.  For now, the simple way to get things working is to just have one big
package profile and use entities for the common things that change.  In the
future, once the system profile and the package managment is developed  it
will be fairly easy to seperate the one big profile into seperate profiles
for each package.

> Someone asked earlier if more than one <programming> element
> should be used...and yes, that's why I chose to put
> %ProgrammingLanguage;+ in the DTD (as opposed to
> %ProgrammingLanguage;?).  I also agree that we should leave as
> much as possible up to the XML parser, even if it results in
> larger file size.

Yes, this concept seems definatly the way to go all around  :)


| Jason at |

Unsubscribe: send email to alfs-discuss-request at
and put unsubscribe in the subject header of the message

More information about the alfs-discuss mailing list