[
Lists Home |
Date Index |
Thread Index
]
Hmmmm.
The proofs for RM were there when Codd published. Nothing similar exists
AFAIK for XML.
What was delivered was quasi RM fulfillment via procedural SQL. I feel that
if SQL was advanced, as a standard, to fully support RM, that an
exponential decrease in SQL maintenance work would be evident from
experience and theory.
I doubt it will take 10 years. XML seems to me to be a middle-ground or
all-compromise technology. In other words, advancing it or optimizing it
for one area of effort will limit its capabilities in another area of effort.
Math proofs are acceptable. Business case proofs are acceptable. But each
of these is in the context of the full lifecycle of the application, and so
an initial experience of high value is not, alone, enough to make the case
or solve the proof.
If such proofs existed, I think they would have been published by now,
given the widespread acceptance and use of XML. Absent such proofs, I think
a _severe_ backlash can be reasonably expected, if XML projects fail
spectacularly over time.
This is what worries me.
Thanks
At 12:25 AM 8/26/2003 +1000, Rick Marshall wrote:
>On Tue, 2003-08-26 at 00:10, pop3 wrote:
> > Thank you for your response, Rick.
> >
> > I agree that the record detail structure is closer, but absent normal
> forms
> > I just don't see how I can (or other folks can) advocate XML only
> > technology solutions in an ISO9000 or CMM compliant shop where phrases
> like
> > "..will use only proven best practices.." are in the statement of work,
> the
> > mission statement, the corporate policies and procedures, or the IT shop
> > process guidelines. In fact, it seems to me that XML usage is clearly a
> > process weakness that should be properly identified as such in various CMM
> > process areas as they are fulfilled.
>that's why there's conservative people and risk taking people and bits
>in between. you may have to wait until it's proven best practice - rdbms
>technology took at least 15 years to be accepted as such, and to a large
>extent i think that what was delivered was proven best brochures and
>proven tier one suppliers - neither has a lot to do with proven best
>technology - but this approach meets all sorts of contractual
>requirements
>
>i guess i'm lucky in having a number of clients who have a different
>approach and encourage use of sometimes experimental techniques to try
>and get a business advantage.
>
>in 10 years or so the experience of early adopters will provide the
>proven technology you need for more conservative projects.
>
>it's all part of our complex business :)
>
>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.
> >
> > 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.
> >
> > 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.
> >
> > 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>
|
