[
Lists Home |
Date Index |
Thread Index
]
- To: XML Developers List <xml-dev@lists.xml.org>
- Subject: XML design patterns
- From: Xasima Xirohata <xasima@gmail.com>
- Date: Wed, 14 Sep 2005 10:02:47 +0300
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type; b=VMbV1r+WN7PGxVh3HAU/7+TyMgQ3ecaD/Y6J8Ng/Zh6udepB9k9C7pIvqoAQN75lTwHPM0Y30HmJyY2Sbg6sQBX/iq5KaAebtkiVWxDrP+0tf21hVzknUjRu2mLYH+fX+O8j6GWb05EFTJmHJ04RBzV7q1VQFe8nlPnACF5BW6E=
- Reply-to: xasima@gmail.com
Hi everybody. I have got a few stupid questions of the
using XML in projects. I
accidentally bumped into these questions when try to discuss
the matter with my colleagues and students.
First of all, what do you know about main principles
and patterns of the design of XML? I
revised my mind and found the following principles. Nevertheless, unlike Object
Oriented Design and Analysis, there is too little (fixed) knowledge to make
somebody expert in this area by book.
==P1==
The first well-known problem that forced us to stop is
the element/attribute alternative. Really elements are ordered, attributes
aren't. It's known that elements allow future expansibility, i.e. the work to
determine more precise information of the given element. Attributes haven't got
this feature. Element determines the (semantic) context for all it's child.
Attribute only characterizes appropriate elements. Thus one may say that it's
more convenient to choose element for the sake of semantic expansibility, explicit
ordering maintenance, flexible abilities to set nested context. In the same
manner one may say that the using of attributes is convenient for the sake of fixation
the most important (key) information of the element or to determine the predefined
(list-like) information, e.g. uid, the string from the list of colors, the
string from the list of language abbreviation and so on.
But I'm afraid that's not enough to make correct
decision. Well..
==P2==
There are a lot of decisions based on such preferences
as brevity, manipulation easiness and so on. I haven't good examples of ML to
show different (!) approaches to design and to show appropriate source ideas
based on brevity decision. Have you got one?
==P3==
The other big problem is to explain what the main
design principles of using namespaces. When should we use namespaces? What kind
of information should we express by namespace dimensions? Is this common
practice to organize URI vocabulary, I mean to express some kind of information
by means of hierarchy in URL? Or is it more convenient to create additional XML
vocabulary in which the information of semantic-similar elements and their
relationship will be stored? Can we treat namespaces as a simple model to
organize semantic similarity grouping of elements and attributes, like first-step
model of the full cross-link vocabulary? I know that the placing namespace
declaration to root-node is only a recommendation.
==P4==
The next idea pretended to be design pattern is «The
Locality of design
approach». It sounds like the following: «You should pass
your XML to local domain experts. They will design (profane ;)) local pieces of
XML. Rely on them. If they make a mistake, you will be sure that all still
correct with the help of this pattern. They know their data better than you do.
Let them make their mistakes by their own. I sure you is a layman in their
mistakes and data. Your duty is only to gather data (and mistakes) in the big
united data (and huge mistake) and to call the result *ML". Am I right to call
it design pattern?
==P5==
So then I tried to reveal my mind what are the main
types of XML I've ever seen. Really it's interesting how design pattern may
depend on different types of XML. In much the same fashion I bumped into my poor
knowledge. There are two extreme types of XML. The first one is data-centric
(raw content). The second one is document-centric (mixed content). The last one
may be told as baby story at night. The other may be migrated from Oracle 2
Oracle at night. But I suspect there exist the quite different XML and it's
possible to set up more high-grade typology. For example what do you think
about the cross link vocabulary? Of course the single document can be
considered as centered in document-data gradation. Nevertheless it's correct to
read this as the page of the book, I mean it's possible to construct such book
(XML stationery) that the sense of each page (sheet) will completely depend on
the information on the other pages. Well, what do you know about possible types
of XML document and what design pattern should we use in each case?
==P6==
So after all I tried to explain XML design principles in
terms of an example.
I noticed that there are few common mistakes made by
newbie (I consider myself to be mature newbie too ;)). For example there is attribute
or element discrimination, the naming of element as «item_2, item_3», context
violation. But I have no capability to
say «you are wrong because you violate design principle №4.5. Look carefully on
the description of the problem. I think it's clear that it's the same as
pattern description №4.5». I'm sure that XML design is not more difficult than
OOD/OOA. Will you be so kind to propose
examples and brief sets of rules?
Thank in advance.
-- Regards, ~ Xasima Xirohata ~
|