[
Lists Home |
Date Index |
Thread Index
]
Xasima, There is an upcoming book from Addison Wesley in this topic; it
is called Patterns in XML. I think it might be published by years-end.
Stay tuned,
F.
Xasima Xirohata wrote:
> 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 ~
|
