new dtd - mkdir element

Mark Ellis mark.uzumati at
Thu Nov 15 10:52:00 PST 2001

On 2001.11.15 01:40 Jay Bennie wrote:
> Hi Mark,
> I'm sure you will have seen my thread/ essays on the project scope? and
> although they are discussing future concepts, one of my more immediate
> goals is to dissect the current schema and nALFS code. I'll probable
> recode either a C++ or java version as an academic exercise to get back
> into coding in C++ and Java. No disrespect to the existing coders, I just
> want to understand this stuff to an equivalent level as yourselves before
> I give any advice. 
> So I'm afraid to say expect some questions/ idiotic statements over the
> next few weeks. :) as I get to grips with the various issues you are
> dealing with. 

Go for it, I didn't know a thing about XML until I started on this, and not
a great deal of perl either.

> On that note before I develop any code, I'll be publishing a spec and
> some UML diagrams, and if you or anyone else has some king of work in
> progress spec for either the code, XML or both that would help out allot.
> (you can email it to me directly at jay at )

Not a great deal of this stuff about at the moment, there is whatever you
can find at the website, and i'm slowly trying to document the perl code
with notes on the profile elements. Dunno about the other guys but I just
don't seem to get the time, and unfortunately it's true that documentation
is always the last thing that gets done :)

> for now though, on the subject of the element, if it were me I would
> suggest the most restrictive schema and extend where exceptions are
> required rather than define a loose schema. if it's loose the code side
> will just get into trouble, especially when we try to do more advanced
> issues such as packaging. 
> Hears another thought? Why just one schema? is it not better to divide
> and conquer? or can all this be defined under one DTD? Sorry I did say
> I'm newish to XML 
> I.e have a List of co-operating DTD's :
> Master profile {                                                     
> //container for the following 
>                     Target platform dtd                             //-
> self explanatory 
>                      Local preference dtd                         //
> indicates something local, i.e user preferences 
>                      SubProfile dtd{                                 //
> Recursive grouping of the following dtds 
>                                             NonsrcPkg dtd          //
> self explanatory
>                                             configscripts dtd       //
> same kind of thing as pkg 
>  // but used for configure scripts i.e /etc/profile
>                                             Pkg dtd                   
> //describes specifics about the individual src pgk 
>  // similar to the make script with extensions indicating 
>   // version, dependency's and external libs, URLs
>                                             PkgDoc dtd               //
> help,man, misc doc's 
>                                             }// end SubProfile
> }// end MasterProfile

I think i get what your saying here. It is true that we've been bandying
around ideas to break up profiles into component parts, then have a master
profile to pull it all together, it's something that'll arrive eventually.
Having a modular DTD is also quite possible as far as i understand it, but
apart from maybe making it more readable I don't think it offers any major

Putting in sections relating to local configuration is also a good plan, it
just hasn't got any further than editing ENTITYs at the head of the profile
however. If you have any thoughts on expanding this then they'll be well

Dependencies, another topic of conversation that hasn't received much
action yet unfortunately. I'm working on something to keep track of
installed files and enable an uninstall, cross reference etc. after the
build, but it still has a way to go and in my mind is more to do with the
backend than profiles, since each installation will differ. Recording other
package details in the profile, such as homepage and download location, you
guessed it, discussed by still just ideas. It would actually be great to
have pre-dependency information available too, i hadn't actually thought of
that in the profile, just as something the admin checked before then build,
but you're right that would be very useful.

> Remember each of these are eventually going to be in separate physical
> files, that would need to be pulled together by the tools to create a
> pseudo schema. something like this perhaps?
> <!Element TProfile ( ARCH, ... )>
> <!Element LProfile ( BuildStatic, LFSPATH , ...)>
> <!Element CSCRIPT (Name, Version, SRC*, DEP*,....)>
> // CScript is a way to list a collection of files and scripts as a
> package, but taking advantage of the DEP features. 
> <!Element SCRIPT (Name, Version, SHELL, SRC*, DEP*, ...)>
> <!Element FILE (Name, Version, SRC*, DEP*, ....)>
> <!Element TARBALL (Name, Version, SRC*, DEP*, CSCRIPT*)> 
> // a posible way to get a group of related files, to resolve dependencies
> <!Element NSRCPKG ( Name, Version, packagetype, Installer,ARCH*, SRC*,
> DEP*, ...)>
> <!Element SRCPGK ( Name, Version, ARCH*,SRC*, DEP*,....)> 
> // DEP is way to link in other dependency objects I.e SRCPKG or NSRCPGK,
> these recur until the dep branches end. 
> // SRC is the URL list of locations to find the required file/pkg 
> <!Element PKGDOC (Name, Version, InstallDir, SRC*, DEP*, ....  )>
> <!Element SubProfile ( CSCRIPT, ( NSRCPKG | SRCPGK ), PKGDOC?)>
> <!Element MProfile (TProfile, LProfile?, SubProfile*)>
> Eventually this would provide a list of entities that include complete
> dependancy chains, with no replication. I have already visualised a
> useful interface aspect which would alert the user to broken dep chains. 
> The only area where this lacks is that I don't know where the build
> instruction files go, or even where the appropriate place to put them is.
> gut instinct suggest that the DTD's that describe build information
> should be contained within the SRCPKG obj as a separate file, this file
> would only then have to describe how to compile the code as all other
> descriptor information is captured in this model. 

At first glance I think you may be trying to overcomplicate matters with
the above, on the other hand I just had the most boring day at work and am
probably half asleep :) But yes, i think the build instructions would go in

> Net Effect.
> 1. a simpler build sequence DTD can be defined - Closer to the aims of
> the current ALFS DTD
> 2. a modular packaging based DTD can be defined which captures
> dependency, src location, ARCH's, versions, and all the other information
> required as prerequisites to the build.(this area requires considerable
> thought)

It definitely needs thought, most of the effort up to this point has just
been getting a basic build syntax to work, we seem to be getting there now
and hopefully can spend a bit of time on other issues.

> 3. the modular system allows for dissolved responsibility - a package
> maintainer maintains the build.xml document and the appropriate xml files
> for the packaging application. 

This is indeed what to aim for, at the moment a great amount of time can be
spent just putting package profiles together, once we have a decent include
system going then sharing of profiles will become much easier.

> 4. Highly customisable distributions. Each branch can be considered an
> object like entity with self validating dependency chains.
>  would we want to do this? am I getting too far ahead for my own good?
> I still see remaining problems but I will have sleep on them for now 
> J

I'd say this is indeed pretty much what we want to aim for, kinda scary how
much there is to do though isn't it :)


>   ----- Original Message ----- 
>   From: Mark Ellis 
>   To: alfs-discuss at 
>   Sent: Wednesday, November 14, 2001 9:23 PM
>   Subject: Re: new dtd - mkdir element
>   On 2001.11.14 20:03 Jay Bennie wrote:
>   > one of this issues that could spell the doom of this project is the
>   > overflexibility of the element definitions, is it not better to
> enforce
>   > the structure, there for providing a situation which is known to be
>   > stable allowing for optionality only where optionality really exists?
>   > 
>   > i.e I'm no expert in XML but what about this?
>   >  (Simply keeping optionals at the end)
>   > 
>   > <!ELEMENT mkdir ( dir, (base | mode)?, mode?)>
>   > 
>   > I have noted that you said the attribs needed to be in order, may i
> ask
>   > why?  
>   > 
>   > PS. it may not be relevant to have a validating dtd at this point,
> but it
>   > may be in the future. Should the question not be how soon would we
> need a
>   > validating dtd? and why? 
>   > 
>   > Jay
>   I actually agree, i like the version that enforces positioning, and i
> think
>   a strong dtd is "a good thing", but since the new synatx is in the
> early
>   stages it needs feedback.
>   In answer to your question, that's just the way a dtd works. Your
> variation
>   is saying the first sub-element _has_ to be dir, which can be followed
> by
>   either a single base or mode element, or base or mode followed by mode.
> So
>   dir mode mode would be perfectly legal according to this dtd fragment,
> but
>   nonsense in alfs terms. Dir base base would be invalid, but equally so
>   would mode base dir.
>   There is actually a more flexible XML Schema, but i get the impression
> it's
>   quite young, and i don't know of anything that actually uses it yet,
> not
>   that i've had a good look. When and if it catches on however, it will
>   actually solve this kind of problem.
>   Mark
>   > 
>   > ------------------------- Original message
>   > --------------------------------------
>   > 
>   > ....
>   > 
>   > And just to see if i can wake anyone up, back to something i
> mentioned
>   > earlier, about the dtd dictating the order of elements. I'm in a
> quandry
>   > so
>   > i'll spell out the options.
>   > 
>   > This  is what i started with, for example using <mkdir> :-
>   > 
>   > <!ELEMENT mkdir (base?, dir, mode?)>
>   > This says mkdir has an optional element base, a compulsory dir, an
>   > optional
>   > mode, and each can appear no more than once. Sounds perfect,
>   > unfortunately
>   > they have to be in that order or it's not valid. I then thought of :-
>   > 
>   > <!ELEMENT mkdir (base | dir | mode)*>
>   > 
>   > This says the three sub-elements can appear in any order, however it
> also
>   > says you can have any or all of them in any quantity, for instance
> six
>   > bases and no dirs, which obviously makes no sense. Next we have :-
>   > 
>   > <!ELEMENT mkdir ((base | dir | mode)?, (base | dir | mode)?, (base |
> dir
>   > |
>   > mode))>
>   > 
>   > So we can have between one and three sub-elements, in any order,
> however,
>   > they can be of any combination, so you can still have 3 bases and no
>   > dirs.
>   > And that is as good as it gets. We can either have freedom without
> proper
>   > validation or validation with a more constrained syntax.
>   > 
>   > I should point out again that this has very little effect on
> backends,
>   > it's
>   > just to do with defining a dtd for the syntax, if we're not bothered
>   > about
>   > a validating dtd it doesn't matter at all. Any thoughts ?
>   > 
>   > Mark
>   > -- 
>   > Unsubscribe: send email to listar at
>   > and put 'unsubscribe alfs-discuss' in the subject header of the
> message
>   > 
>   > 
>   -- 
>   Unsubscribe: send email to listar at
>   and put 'unsubscribe alfs-discuss' in the subject header of the message
Unsubscribe: send email to listar at
and put 'unsubscribe alfs-discuss' in the subject header of the message

More information about the alfs-discuss mailing list