Lists Home |
Date Index |
I'm currently developing a set of schemas for a Government Department
which deals with education and I've got some questions about managing
dependencies and namespaces. This is a bit tricky to describe so please
bear with me.
Currently I have the following namespaces corresponding to individual
schema files (these are just example dummy URIs to get the concept over)
LEVEL 1 - "core business object Schemas"
LEVEL 2 - "Instance Schemas"
Specific document and message formats which implement various elements
from each namespace and other OASIS namespaces.
I'm about to remodel this to avoid dependencies between my level 1 core
schemas and I also have the feeling that this level or granularity maybe
I think I have three options -
1) Create one organisation wide namespace containing models of
classifications, standards and qualifications in the one file (I like
this because in the future it might be clearer where we can separate out
namespace specific objects once it's clearer where that may be necessary).
2) Chain the Level 1 schemas. My main dependency problem comes when I
try to model a classification tree that contains standards so I guess I
could import standards into classifications.
3) Create another namespace between level 1 and 2. I don't really think
that's a solution just an option.
I guess my main question is -
What things do you think about when you decide a schema requires split
up into different namespaces?
Can you point me at any articles on best practice in this area?
Does anybody have any thoughts or experience?
Does anybody know what I'm on about??
SolNet Solutions Limited
L12, SolNet House, 70 The Terrace
PO Box 397, Wellington, Aotearoa / New Zealand
This email may contain information intended for the sole use of
the original recipient. Please respect this when sharing or
disclosing this email's contents with any third party. If you
believe you have received this email in error, please delete it
and notify the sender or email@example.com as
soon as possible. The content of this email does not necessarily
reflect the views of SolNet Solutions Ltd.