[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XML design patterns

• To: xasima@g...
• Subject: Re: XML design patterns
• From: Fabio Arciniegas <fabio.arciniegas@p...>
• Date: Sun, 25 Sep 2005 08:51:06 -0400
• Cc: XML Developers List <xml-dev@l...>
• In-reply-to: <7d645304050914000219222c32@m...>
• References: <7d645304050914000219222c32@m...>
• User-agent: Mozilla Thunderbird 0.9 (Windows/20041103)

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 ~ 

• References:
  • XML design patterns
    • From: Xasima Xirohata <xasima@g...>

• Prev by Date: Re: Wrapping Scripted Media in RSS: Secure?
• Next by Date: Semantic equivalence of xml documents
• Previous by thread: RE: basic qs - how is xml more flexible for exchanging data?
• Next by thread: Question regarding XSD structure
• Index(es):
  • Date
  • Thread