Reputation: 11757
We are currently working on the design of a RESTful application. We have decided on XML as our basic representation. I have the following questions regarding designing/modeling the application data in XML.
Note: I have already looked at a related question at stackoverflow (What are best practices for designing XML schemas?) but that doesn't seem to address the above questions.
Upvotes: 2
Views: 374
Reputation: 51
Its better to think of namespace design approach from the start. If the XML files you are going to design are conceptually related you could go for homogeneous namespace design approach.
Heteregeneous namespace design approach allows for sharing and reusability. This could be used when you would like to visually identify domain-specific files.
The heterogeneous design approach is the recommended way. Refer http://technologyandleadership.com/three-schema-design-approaches/ to know how to implement this design approach for your project
Upvotes: 0
Reputation: 161773
I agree that you should first design your application, and decide on what information you need to exchange.
As you're doing that, you may possibly find that some of the information you're exchanging comes from standard schemas. You may also find that there are standard schemas used by your customers, that already describe the information you want to exchange.
If neither of these things occurs, then forget about "standard schemas". Among other things, I don't think you're going to find a comprehensive list of them - there are too many.
Upvotes: 0
Reputation: 95604
One thing to note about service design is that it is different from designing class/object, and you have to think more in terms of exchanging documents. This is sometimes called course-grained. In OO world, you'd be exchanging series of method calls between peers, but in SOA, you'd avoid chattiness and try to stuff most of the information needed into a document, sort of like filing a tax form.
Upvotes: 1
Reputation: 10841
If you don't have an XML already and don't know the requirements than it will be hard to design the schema first. If you have code already that has to deal with XML than it may be the best idea to take the object tree as an example for your first XML tree. They aren't that different except that XML is always just a tree and your objects not.
From then one stabilize your XML and collect requirements what use cases should be modelled with it. If you have this two you have a perfect start to do an schema. This will solidize your format.
Looking for standard schemas is always a good idea but is almost all the time frustrating, too. Postpone this until you know what your xml will look like. Maybe then you recognize there is already something standardized that is just as your format.
You should be careful about namespaces. This is a more heavy weight topic in XML because you can do so much wrong. If you are not sure that you need them then skip. That is what the rest of the world is doing. If you think you will need them start at the very first to use them. Mixing none namespace aware code and namespace aware code is a pain.
Upvotes: 2