[
Lists Home |
Date Index |
Thread Index
]
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>
|
