Best way to find starting directory

[Frank Millman]

On 20/03/2013 10:56, Dave Angel wrote:
> On 03/20/2013 01:58 AM, Frank Millman wrote:
>> On 19/03/2013 17:03, Dave Angel wrote:
>>> On 03/19/2013 10:29 AM, Frank Millman wrote:
>>>> On 19/03/2013 14:46, Dave Angel wrote:
>>>>   <SNIP>
>>> In putting them there, you are making two assumptions.  One is that only
>>> one user will ever run this, and two is that the user will not need two
>>> sets of those 'schemas'.  If the user is tracking two different
>>> companies, each with the same code, but different xml and different
>>> database, this would be the wrong place to put it.  But it's up to you
>>> to decide those assumptions, not I.
>>>
>>
>> Maybe I did not explain very well. I fully expect a large number of
>> users, tracking a large number of companies, to access the same schema
>> file at the same time.
>
> So the scheme does NOT describe an individual company, but something
> more general?  Presumably there's a separate database per company?  Why
> then is the schema separately stored in each database?
>
>>
>> In fact I use lxml to parse the xml once it has been read from the
>> database and decompressed. There are a limited number of 'types' of xml
>> file (form definition, service definition, report definition, etc), and
>> each type has its own schema. lxml will use a validating schema if you
>> pass the path to the xsd file as a parameter to the parser. I create
>> separate parsers, one for each type, when the program starts. But I
>> still need to tell it where to find the xsd file.
>>
>> They are stored in a sub-directory called 'schemas'.
>
> Clearly I don't understand your model well enough to advise you one way
> or the other.  All I can do is ask questions whose answers might remind
> you of things you know but I do not.
>
> This code is running on a server, with simultaneous users?  And all
> users who run it will be using identical xml, which will only be updated
> when a new version of the script is installed?  And each time a user
> starts the application, you read the xml from the database, write it to
> a sub-directory 'schemas'  and subsequently in the run you access it
> with lxml?  You've considered what happens when one user is creating the
> files, while another user is still accessing them?
>
> Are these 'files' so enormous that you can't just use in-memory file
> objects?
>
> The analogy to global variables must be clear.  They're fine if they're
> constant.  But as soon as you have multiple threads making new versions
> of them, everything can easily get out of whack.
>

Dave, I really appreciate your input, but we are talking at cross 
purposes somewhere along the line - I am not sure where.

Firstly, just to ensure there is no confusion, I am not talking about 
*database* schemas, I am talking about *xml* schemas. From Wikipedia, 
"An XML schema is a description of a type of XML document, typically 
expressed in terms of constraints on the structure and content of 
documents of that type, above and beyond the basic syntactical 
constraints imposed by XML itself."

Let's focus on 'form definitions'. What I call a 'form' is something 
that can be displayed on a user's screen, for data entry, data display, 
or both, containing text, input fields, checkboxes, buttons, etc, etc. I 
have devised an xml format to describe the form. When requested, the xml 
file is read in and sent to the client, which extracts the elements and 
renders them on the screen.

All form definitions are stored in the database. To ensure that they 
conform to the standard structure which the client is expecting, I have 
written an XML schema that can be used to validate the content.

The XML schema is stored in its sub-directory permanently. Once 
debugged, it will never be altered. It is the equivalent of source code, 
that is read and interpreted at execution time.

When a user selects a menu option, the form definition is read in from 
the database, parsed and validated by lxml using the schema, and if ok 
it will be sent to the client for rendering. Otherwise an exception will 
be raised.

Hope this makes more sense.

Frank