OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ubl-ndrsc message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: RE: [ubl-lcsc] RE: [ubl-ndrsc] Functional Dependency and Normalization paper

(my citation software stinks, so I must ask your forgiveness for always
responding at the head of the thread)

Further (along Eve's thread) it's interesting to note that without any use
of ID and IDREF or KEY and KEYREF the instance documents resulting from the
normalized (3NF) schema in Tim's example are non-normalized in at least one
important sense.  While the _schema_ has been normalized, the instance
document still contains repeated records=objects=content.  

We've got an approach to normalize the XML Schema -- which is essentially
like a database schema.  What we do not have is an approach to normalize the
_serialization_ of structures conformat to that schema.  This is an area for
innovation -- relational theory doesn't have a serialization problem.  The
database is everything.  We've got two views here (kind of).  An
almost-database view (XSD) and (possibly many) serialized views of that.

I agree that we in NDR need to tackle the issues around IDREF and friends,
and further, that it needs to be done in the context of our normalization
discussion.  Also, I think that the issue of normalizing the serialization
falls pretty cleanly under the NDRSC charter and expertise.  With our joint
work on normalization of the logical model as a starting point it seems like
NDRSC ought to be able to go forth and tackle the serialization.


-----Original Message-----
From: Eve L. Maler [mailto:eve.maler@sun.com]
Sent: Wednesday, September 11, 2002 9:50 AM
To: 'ubl-ndrsc@lists.oasis-open.org'; 'ubl-lcsc@lists.oasis-open.org'
Subject: Re: [ubl-lcsc] RE: [ubl-ndrsc] Functional Dependency and
Normalization paper

Tim McGrath wrote:
> Burcham, Bill wrote:
>> In 1NF (in appendix A) at the point where you've found the one-to-many
>> relationship between "order" and "order item" and you've shown the 
>> need (in
>> the relational model) for the "linkage" from "order item" back to "order"
>> via the foreign key.  It seems worth noting at that point that this 
>> linkage
>> is explicit in the relational model but implicit in the (eventual) XML 
>> one.
>> This linkage between "order" and "order item" will be inferred from the
>> context -- an "order item" is associated with the "order" under which it
>> appears.  We'll see this again and again.
> I see the terms linkage, relationship and association as fairly similar. 
> In a relational model these are implemented by foreign keys, in XML by 
> including the associated element within the container (sorry, the 
> language gets in the way here - maybe we should just get down to 
> diagrams!).  It is just different ways to implement the same concept. 
> Not sure i like 'explicit' and 'implicit' - we could just say that one 
> may be more elegant.

XML's primary means of association is containment, but it also allows 
for association by reference.  The built-in XML datatypes of ID and 
IDREF[S] are one way, and XSD provides another that it actually calls 
"keys", a la RDBMS's.  (Personally, though, I think it's still high-risk 
to use the XSD key mechanism.)  You can also invent any number of 
application-specific linking mechanisms, or even use the Web's URI 
paradigm for addressing resources.  The NDR group has been trying to get 
to the topic of how to do content-by-reference and it looks like we'll 
have to push this higher in the stack...


Eve Maler                                        +1 781 442 3190
Sun Microsystems                            cell +1 781 883 5917
XML Web Services / Industry Initiatives      eve.maler @ sun.com

To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Powered by eList eXpress LLC