new dtd - mkdir element

Jay Bennie jay at
Wed Nov 14 17:40:23 PST 2001

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. 

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 )

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

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. 

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)
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. 
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 


  ----- 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.


  > ------------------------- 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the alfs-discuss mailing list