OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   XML design patterns

[ 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 ~



 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS