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


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] RE: When the required output data can't be producedwith a tool, does it indicate the XML document is poorly designed or a newtool is needed?

  Costello, Roger L. skrev 2010-09-26 16:08:
> Hi Folks,
> How does one identify a well designed XML document? Is XML design simply a matter of aesthetics; or, are there solid engineering/scientific/mathematical principles behind good XML design?
I do not know of any XML method, but I do know data modeling methods 
that can be applied to XML design. For certain properties such as 
efficient processing, there are engineering ways of designing XML 
structured data. For example, it is possible to employ entity 
relationship modeling and in a similar vein to normalization in 
relational schema, you can try to reduce dependencies between entities. 
Further, in a data modeling for databases, then you check for the 
queries you want to ask and adapt the schema to fit the queries. In a 
similar vein, you can consider the processing of XML structured 
(effectively, tree-structured data) and adapt the representation with 
respect to processing.

Mind you, processing is an important aspect, but if you want debugging 
capability by reading the XML structured data in raw format, then you 
need to consider what is the most natural way to understand the data. 
There are more examples such as this, for example, information 
redundancy to detect or repair faulty data, etc.

Typically, design is iterative, where you bring in various aspects that 
you use to test your design.
> How does one identify the right tool to process XML documents? Is tool selection simply a matter of using whatever tool happens to be available; or, are there engineering/scientific/mathematical principles behind the selection of tools for processing XML documents?
Well, basic process: consider the requirements of your processing, see 
how well various tools matches these requirements while considering how 
skilled the staff is at the tool. For example, if there is an excellent 
tool for your processing, but no one at your organization knows it, then 
the question is whether it is worth learning the tool or to use an 
inferior tool hat your organization knows well. The legacy impose 
serious requirements and may require that you do not employ the best tools.

In utopia, skip the legacy and ignore the skill of your organization.

Tool selection is typically also iterative.

/Jonas Mellin
> /Roger
> _______________________________________________________________________
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

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

Copyright 1993-2007 XML.org. This site is hosted by OASIS