[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: tpassin@h...
  • To: "Kay Michael" <Michael.Kay@i...>, <johns@s...>, "'Jean-Marc Vanel'" <jmvanel@f...>, <xml-dev@x...>, <wwbota@e...>, <daniel.rivers-moore@r...>, <Ioana.Manolescu@i...>
  • Date: Sun, 9 Jul 2000 22:07:14 -0400

billing xml schema
Kay Michael observed -

> > "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?
>
I don't have any single answer, but here are some more thoughts -

* Suppose you have several different types of addresses you could put in an
element (billing, shipping, etc.) - and more than one could appear.  It is
useful to call them all "address" because then it is easy for the processor
to know they are all the same kind of thing.  So it is easier to send them
all to the same address processor.  But you have to differentiate between
the different addresses somehow.  This argues for something like the "role"
attribute, although you could do it some other way, like a "role" child
element.

* If you mangle the names, you are getting into a very private coding
scheme, and you have to parse the names.  Why add another parsing method
when you are already using xml parsing?

* The issue is very different if the different type of addresses are really
different types, are fomatted differently, and need different processing.
Then it would be natural to use different names, whether dotted or
otherwise.

* If you are interested in a billing section (in this example) which as
other information in addition to an address, then the form
<billing><address>...</address><amount>...</amount>...</billing> would seem
fairly natural.

Regards,

Tom Passin


***************************************************************************
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.