Re: [xml-dev] XPath and a continuous, uniform information space

[Uche Ogbuji <uche@ogbuji.net>]

On Fri, Aug 16, 2013 at 8:55 AM, David Lee <dlee@calldei.com> wrote:

( I am not quite sure of the later ... is doc("x" ) == doc("x") ? ) 

Yes.  From the XSLT 1.0 spec, 12.1:

--

Yes I get that part, but thats to solve the immutable problem.

Uh no. That's just to set up an axiom that answers all the questions you seem to be asking on the subject.  the answers are either "yes" "no" or "out of scope."

 

My statement/question is more about document identity - outside of xpath().

What exactly?  XML does not define document identity at all, so your question is null in that context.  If you don't mean XSLT, what other specific context of XML do you mean?

 

XPath defines node and document identity for the purposes of that particular invocation but really skirts the whole

Actually XPath doesn't.  XSLT does.  Nit-picky but a very important point in the intended separation of concerns.

 

concept of document identity in the outside world.  Not that it *could* address that problem.

I was going to make a cheeky quip about how it also doesn't solve the identity of the Brahma versus the Atma, but I'll just instead ask why you think any one spec needs to solve such a problem.

 

But just to cite some interesting problems.

 

1) 1 URI invoked twice *could* produce different document contents.   Are they the same document ?

In what context?  Again, in XSLT the answer is yes.  That axiom is there to answer that problem.

 

2) 2 different URIs could refer to the same document.

In the case of XSLT they are *not* the same problem, even if they look the same.  Just as 2 statues of the Buddha are not the same thing, even though they are identical in every regard.

3) Documents could be transient, dynamic and unnamed ...

Of course they could.

 

What is more to my point is ... if we were to support a web-wide "InfoSpace" we have to more clearly define (or skirt)

the concept of indirecting URI's ... And a core concept in this thread is an issue with XML itself being "document centric",

I'm not sure I understand the above, but again there are plenty of RFCs and other specs that deal with such matters.  Remember that there is already a concept of a Web-wide "InfoSpace."  It's the Web.  It happens to be useful regardless of the fact that not every ontological question has been answered.

 

Michael Kay's talk on Ftan was very interesting in that they resolved that issue by getting rid of node identity ... but along that so went the parent and sibling accessors !  But maybe thats the price to pay ...

Whether or not you have node identity should depend on the details of a given processing stage, and I think it's bad architecture to have coupling of node identity across processing stages.  I think of node identity it a bit like a C pointer in that regard, or a CPU address register, if you prefer.  I'm surprised such a matter would be relevant to an expression language as opposed to a processing spec.  But then again maybe by "Ftan" you mean some specific processing mechanism associated with Ftan.

To really implement the concept of a Info Space I am feeling we need to drop the concept of "documents" much like Ftan does.

I don't think it's really important either way.  MicroXML does drop the concept of a document but IMO that alone doesn't address the fundamental idea of an "InfoSpace."

Probably a good idea for me to say that this discussion doesn't really interest me in terms of achieving some monolithic "InfoSpace."  As far as I'm concerned, we already have something as close to that as we should ever venture: it's the Web.  My interest is in a bit of pragmatic loosening of the way an XML parser starts out with its input tokens, and maybe invokes pattern-based sub-processing such that the ultimate stream of tokens is not deterministic.  One possible subprocess could be accessing resources on the Web.

Such an architecture would support the sort of "database" capability with which Michael started this thread.  But it would keep the right layering and separation of concerns overall.

Building this entire "InfoBase" concept into one huge cathedral of a standard/spec/convention/whatever is IMO a guaranteed train-wreck.  But not a big deal since it's probably so impractical as to be impossible.

 

But that doesn't solve accessibility and reliability ...

How do we make a Web based InfoSpace that is reliable ... without having to have a local copy of it all ?

 

We don't.  

--------

 

So your opinion is that a web based InfoSpace is impossible or impractical ?

So impractical as to be impossible.  Not really an important distinction to me.

--
Uche Ogbuji                       http://uche.ogbuji.net
Founding Partner, Zepheira        http://zepheira.com
http://wearekin.org
http://www.thenervousbreakdown.com/author/uogbuji/
http://copia.ogbuji.net
http://www.linkedin.com/in/ucheogbuji
http://twitter.com/uogbuji