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

RE: Property role and domain (was: Playing with XML Schema & XSLT)

  • From: johns@s... (John F. Schlesinger)
  • To: "'Kay Michael'" <Michael.Kay@i...>, "'Jean-Marc Vanel'" <jmvanel@f...>, <xml-dev@x...>, <wwbota@e...>, <daniel.rivers-moore@r...>, <Ioana.Manolescu@i...>
  • Date: Thu, 6 Jul 2000 07:59:14 -0400

daniel codd
Mike Kay wrote:
"This need to represent both the role of a property and its domain has
always
been a problem in data modeling, for example the concept of domain was in
Codd's original relational model but didn't make it into SQL until much
later, and never made it into the core of the language."

I think we can exaggerate the extent to which designing XML messages and
documents is data modeling. An XML message from one business object to
another is more like a view than a table - that is, it represents one
application's view of, perhaps, a large number of tables. The mark up should
reflect that view and say as much as possible about what the application
means by the information it is sending or receiving. That is why I don't
like elements called <Address>, <Date>, <Name> or <Phone>. If you replace
them with <WhereToBill>, <WhenToBill>, <WhoToBill> and <AssistantPhone> you
are pinning down much better what you mean by the elements.

Yours,
John F Schlesinger
SysCore Solutions
212 619 5200 x 219
917 886 5895 Mobile

-----Original Message-----
From: Kay Michael [mailto:Michael.Kay@i...]
Sent: Thursday, July 06, 2000 5:35 AM
To: 'johns@s...'; 'Jean-Marc Vanel'; xml-dev@x...;
wwbota@e...; daniel.rivers-moore@r...;
Ioana.Manolescu@i...
Subject: Property role and domain (was: Playing with XML Schema & XSLT)


> "About that, I regret that the first example in the
> introduction to XML Schema has a tag <shippingDate> , and not
<shipping><date>, > which is extendible, and allows machine understanding."
>
This need to represent both the role of a property and its domain has always
been a problem in data modelling, for example the concept of domain was in
Codd's original relational model but didn't make it into SQL until much
later, and never made it into the core of the language.

For XML I struggled a little to identify best practice on this when writing
Chapter 4 of Wrox Professional XML: the discussion of alternative approaches
is on page 129-130. I came to the conclusion that <Billing><Address> was
probably preferable in theory to <Billing.Address> or <Address
role="Billing"> or <Billing type="Address">, but rather clumsy in practice;
and in the end I dodged making a firm recommendation.

Any other views on this? Does it become easier with XML Schema replacing
DTDs?

Mike Kay


***************************************************************************
This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@x...&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/
***************************************************************************

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.