[
Lists Home |
Date Index |
Thread Index
]
pop3 wrote:
> Thank you for your response, Rick.
> I see RM as a proven best practice because I have seen and have
> reproduced RM proofs. I do not see XML as a proven best practice for
> anything because I have not seen and have not been able to develop XML
> proofs. Perhaps proofs exists that have not been publicized for XML
> document markup or perhaps XML data interchange as a best practice. But
> it is highly doubtful, at least to me, that proofs exist or can be
> developed for XML as a best practice for data management, data
> maintenance, data support, data systems, document management,
> programming (compiled code or interpreted code) or logic structures.
This thread keeps dangling too close to comparing XML and the Relational Model, and now XML vs CMM.
Rant: Which stakeholder has "The One Correct" world view? In all situations, can all information be managed in a unified storage system? No. Will there often be multiple systems, legacies, and non-relational sources? Yes. It is common for engineers to invent proprietary formats for modelling and maintaining information about their designs. Does it make sense to manage that as XML instead? Yes. They are going to invent it anyway, and at least with XML I can get editors and specific techniques to translate the format. Does it make sense to build a relational database for it? In many cases, absolutely, positively not. Too much work, too little payback, and it can be done later if and when the understanding of the problem matures. Does it make sense to allow local organizations to address local technology needs without conforming to a global data management practice? Yes. Organizational policy may dictate that "all our relational databases are managed through our central Oracle
support organization". If it takes six weeks and half a dozen conference calls just to get the DBA to create a new tablespace for a new customer support troubleshooting tool, someone is completely missing the point. Best practices are worse than useless when they prevent workers from actually achieving real work.
End Rant
> If there are mathematical proofs (set theory, set calculus, etc) , other
> rigorous scientific proofs, or even significant business case proofs (
> in a rigorous business management sense), then I would really like to
> hear them, and see them presented here, or on a W3C web site or
> someplace public like that.
The best signal to noise ratio location I can recommend, is the Extreme Markup site.
http://www.extrememarkup.com/extreme/
> Without such I cannot endorse or advocate use of XML for anything other
> than as a markup language, or maybe data interchange. IE uses such as
> for embedding logic in documents, "compiled binaries", "database" or
> even "document management". Nor can I support folks in a CMM or ISO9000
> shop utilizing XML to any significant degree until they can show that
> XML is a proven best practice, by rigorous scientific proofs.
XML works reasonably well as a markup language.
I hear what you're saying about supporting CMM and ISO9k shops. However, I've seen too many shops rife with entrenched bad practices supported by legacy, political alliances, FUD, and money. Too many to say that scientific proof is really a characteristic of a CMM or ISO9k shop. What I suspect will happen is that XML will continue to entrench itself throughout the infrastructure, and at some point (if it hasn't already happened yet) people will simply assume that utilizing XML is a best practice (no matter what the scenario).
> Mebbe I am just dense. Mebbe I just don't get it.
>
> Thanks again.
>
> At 12:46 AM 8/21/2003 +1000, you wrote:
>
>> <oxymoron>relationally structured data</oxymoron>
>>
>> of course you can represent records, but as soon as you make a tree out
>> of them they're not relational in a database sense
>>
>> eg
>>
>> <customer>
>> <name>COMPANY X</name>
>> <town>SOMEWHERE</town>
>> <order>
>> <part>ABC123</part>
>> <quantity>2</quantity>
>> </order>
>> <order>
>> <part>ABC234</part>
>> <quantity>4</quantity>
>> </order>
>> </customer>
>>
>> just isn't going to be a relational form as there's no way to determine
>> a priori what the normalised records are. there's clearly 2 tables, and
>> you know that "customer" has attributes name and town, and "order" has
>> attributes part and quantity, but it also needs either name or town to
>> complete the relation and it's not obvious which. either or both?
>>
>> so without some semantics you can't represent relational tables with the
>> natural tree structure of xml.
>>
>> on the other hand
>>
>> <customer>
>> <name>COMPANY X</name>
>> <town>SOMEWHERE</town>
>> </customer>
>>
>> <order>
>> <name>COMPANY X</name>
>> <part>ABC123</part>
>> <quantity>2</quantity>
>> </order>
>> <order>
>> <name>COMPANY X</name>
>> <part>ABC234</part>
>> <quantity>4</quantity>
>> </order>
>>
>> is ok, but then from what i've seen on the list most wouldn't think of
>> this single depth as the natural thing to do.
>>
>> my personal preference (and used day to day) is:
>>
>> <table name="customer">
>> <record>
>> <attribute name="name">COMPANY X</attribute>
>> <attribute name="town">SOMEWHERE</attribute>
>> </record>
>> </table>
>> <table name="order">
>> <record>
>> <attribute name="name">COMPANY X</attribute>
>> <attribute name="part">ABC123</attribute>
>> <attribute name="quantity">2</attribute>
>> </record>
>> <record>
>> <attribute name="name">COMPANY X</attribute>
>> <attribute name="part">ABC234</attribute>
>> <attribute name="quantity">4</attribute>
>> </record>
>> </table>
>>
>> and a few minor attribute additions. but again i suspect this is not
>> what most use, but then i'm happy to proved wrong.
>>
>> rick
>>
>> On Wed, 2003-08-20 at 22:52, Chiusano Joseph wrote:
>> > <Quote>
>> > Unless someone can show me how XML or an XML only tool set such as
>> > TeraText supports and fulfills RM,
>> > </Quote>
>> >
>> > Are you asserting that one cannot represent relationally structured
>> data
>> > using XML? If so, can you please elaborate?
>> >
>> > Kind Regards,
>> > Joe Chiusano
>> > Booz | Allen | Hamilton
>>
>>
>>
>> -----------------------------------------------------------------
>> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
>> initiative of OASIS <http://www.oasis-open.org>
>>
>> The list archives are at http://lists.xml.org/archives/xml-dev/
>>
>> To subscribe or unsubscribe from this list use the subscription
>> manager: <http://lists.xml.org/ob/adm.pl>
>
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://lists.xml.org/ob/adm.pl>
>
>
|
