* dave sag
| I am trying to implement some pretty simple scenarios in xml and i
| keep running into walls.
| there seems to be no way for an xml object to
| 1. extend other objects
| 2. guarantee its uniqueness
| 3. be truly resused by other objects
I think a great part of this is very likely due to the way you think
about XML. For example, what is an XML object? To me the term simply
means that you're thinking in terms of other data representation
technologies than markup.
| i have a client they are either a person or an orgnisation if an org
| they have a representative which is a person they both have phone,
| fax, email etc
This sounds like the sort of stuff RDBMSs were invented for and for
which they have probably been the best technology on earth for about
For such data, XML may be very useful as a data exchange and transport
format, but not really for storage. Or, which is perhaps better, for
management. You want something other than XML to _manage_ this sort of
| people can log into my siet and change their details so if person x
| who is a representative of org y logs in and updates their address,
| that change must trickle though to the org they represent. this it
| makes no sense to store a full copy of the person in the org.
This is the sort of thing which RDBMSs and SQL do such a good job of
that there's not all that much point in looking for other solutions.
(Well, OK, embedded SQL, perhaps.)
| but if i store at person in the org as a reference, how do i then
| access properties of that person in the context of the org
| ie: orgname.people[personName].firstName
| is this sort of referencing built into all xml parsers
A parser is something that takes a sequence of bytes and turns it into
something higher-level. In the case of XML that something is elements
and attributes. So, in other words, an XML parser is a deserializer
that gives you back the elements and attributes you stored away
somewhere. If you want an API for manipulating XML documents you can
use the DOM, but you will then need to write the manipulated document
back into your data store afterwards.
There's nothing that keeps people from writing persistent DOMs where
the XML serialization syntax (what is commonly known as REC-XML-1.0 :)
is done away with completely (and in fact people have), but this is
not common, which probably has a lot to do with the traditional uses
of markup and the way people still think about it.
It's worth remembering that XML comes from a document context and is a
descendant of something that provided the solution to questions like
"Well, we have 18'000 documentation deliverables for every model of
aircraft we produce and we need to produce documents in all these
formats and we have to maintain it for the next 50 years. What should
we store it in?"
| also i want to write stories about jobs, orgs or people. so a job
| object would have a client, story object an author (a person) and a
| subject (a job, person or org) s well as the story proper.
Now we're talking about something for which XML probably is a much
better fit, depending on what you mean by story.
I don't really understand your requirements from what you write, but
it's beginning to sound like you should do standard relational data
modelling for everything except the stories, maintain the stories in
XML, and store everything in an RDBMS with the stories as XML blobs.
Just an idea.