RE: [xml-dev] XML Data Modellling/Linking (was RE: [xml-dev] AfterXQuery, are we done?)

["Hunsberger, Peter" <Peter.Hunsberger@STJUDE.ORG>]

Ronald Bourret <rpbourret@rpbourret.com> writes:
> 
> Michael Champion wrote:
> > On Fri, 22 Oct 2004 21:15:54 GMT, rpbourret@rpbourret.com 
> > <rpbourret@rpbourret.com> wrote:
> > 
> >>Michael Kay wrote:
> >>> Why can't we have multiple hierarchic views of the same 
> network? Why 
> >>> do all my queries have to change depending on whether my 
> footnotes 
> >>> are inline, out-of-line referenced by IDREFs, or in external 
> >>> documents referenced by URI? What happened to the old doctrine of 
> >>> data
>  >>> independence?
> > >
> >>Hmmm... Sounds like the relational model. (Sorry, couldn't resist.)
> >>
> >>I think this could actually be dealt with at the query 
> language level,
> > 
> > I hope you're not joking :-)
>  >
> > The CODASYL data model ultimately foundered because of its unwieldy 
> > links, and XLink foundered trying to do something similar for XML. 
> > Maybe the lesson here is that the relational model approach of 
> > defining links *dynamically* based on relationships on the 
> *values* of 
> > information items rather than predefined links really is 
> the way to do 
> > what XLink tried to do.
> 
> Agreed, but it's also part of the catch.
> 
> Operators that automatically knew to follow links would have to know 
> that links are in fact links. And since it is unlikely that 
> the values 
> being used to make the link are URIs, they would also need 
> some sort of 
> information about the link target.
> 
> For example, given the element <part>123</part>, it would be nice to 
> link this with a document containing more information about part 123, 
> but XQuery would need to know where to go looking for that document.
> 
> One possibility is some sort of external document containing link 
> information, as Dave Pawson suggests. Note that this could be in the 
> form of schema annotations, as this is the normal source of such 
> information for XQuery. [Insert groans from the 
> I-don't-like-mixing-schemas-and-queries crowd here.]

The schema notation idea seems to be poking it's head through in several
spots in this thread.  I sort of wondered if that was what Michael was
getting at originally, though I hesitated to ask the question directly
perhaps more because I don't like mixing schemas with anything than
because I don't like mixing them with queries.  

I've actually some comfort with using schema at query construction time,
any sophisticated ad-hoc query construction tools want access to schema.
If you support multiple type attributes for an element than adding an
additional notation that a given element describes some form of
relationship can't hurt.  The problem comes when you have to choose
between saying something is an relationship or it is a sequence of
numbers or such.  I don't think W3C schema as it currently exists is
going to work for this, we need polymorphic schema.  The saving grace
may be layers of schema, but then you get into your second problem:

> While schemas might be a good place to tell the query that an 
> element or 
> attribute represents a link, I don't think it's a good place to put 
> information about where to go to resolve the link, as the schema is 
> portable but location information, such as where a parts 
> document is, is 
> not.

I agree you have to separate the link resolution out.  If you need to
link multiple schema in order to have relationship management you've
just bumped the problem up a metadata level.  Now you need a way to
resolve what schema is applicable for what view of the data.
 
> The other obvious source of the information is the query itself, but 
> then we've already got this :)
> 
> On a related point, I think it would be nice to be able to just say, 
> "This is a link," without any of the additional explanatory 
> information 
> that XLink gives (type, role, etc.). The advantage of this is 
> simplicity, and it really isn't that unreasonable when you 
> think about 
> it: Most interpretation of XML documents is application 
> specific anyway, 
> so why should links be any different?
> 

Umm, so you can built the semantic web? (Running and ducking...)