RE: [xml-dev] Are documents loosing the web?

[Len Bullard <len.bullard@uai.com>]

I agree that it is about linking.   At a certain point in the Hytime design
saga, someone made that assumption and began to build on it.  DSSSL,
styling, etc., kept dragging us back to the document model.

I don't have enough time for this reply.  We are pushing a build out.  So
let me ask the same question again about XML:  are we at the point of
understanding where it is more useful to discuss the document model in terms
of combinatoric standards and to state that messaging is not effectively a
document model?

In linking, at some point, the web cognoscenti began to talk about resources
instead of documents.  This is one place where Hytime and the WC coalesced,
IMO.

len

-----Original Message-----
From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com] 
Sent: Tuesday, February 19, 2008 4:11 PM
To: Len Bullard
Cc: Michael Kay; 'Eric van der Vlist'; xml-dev@lists.xml.org
Subject: RE: [xml-dev] Are documents loosing the web?

(finally catching up with this thread)

One of the reasons that the "document" model is so compelling on the Web 
is that it's closely tied to linking, I think.  Let's say I have a program 
that's just running along.  I want to show you something from that 
program.  What do I link to? 

Now consider something like Google maps.  It's not as obviously a 
"document" application as would be a simple Web page.  You can drag the 
map in a nearly analog way, you can zoom, etc.  Crucially, though, there's 
a sort of document metaphor layered on all this.  If I want to show you 
the map of the W3C's Headquarters, I can ask my client and get this link (
http://local.google.com/maps?f=q&hl=en&geocode=&q=mit+stata+center,+cambridg
e,+ma&ie=UTF8&ll=42.36682,-71.100898&spn=0.01931,0.038452&z=15&iwloc=A
).  So, there's a sense in which the state of the application is modeled 
as a nearly infinite set of documents, a subset of which I see in sequence 
a I interact with the application.  That's not a concept that we would 
have bothered to apply to the structure of Lotus 1-2-3, say, because there 
was no value.  In that application, you just zoomed, scrolled, etc., and 
most of the application's state would be saved to a file when you asked 
for that. 

So, I think it's too facile to just say that the time is passing for 
documents as an organizing principle for applications.  It's always been a 
tradeoff, but I would argue that the Web, and linking in particular, 
encourages us to think in terms of document views of applications, at 
least in many cases.

Noah

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








Len Bullard <len.bullard@uai.com>
02/01/2008 01:42 PM
 
        To:     Michael Kay <mike@saxonica.com>, "'Eric van der Vlist'" 
<vdv@dyomedea.com>, xml-dev@lists.xml.org
        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
        Subject:        RE: [xml-dev] Are documents loosing the web?


The question is then, is every document that can be received eligible to 
be
received by any and all receivers?  Otherwise, where is the 'defined' and
presumably shared interpretation to be found.

I really don't have sympathy with the document position.  It begs the
complexity of having all applications available to all other applications
all the time.   That's Panglossian.

Walled gardens are not just a fact of the web.  They are a preferred way 
of
life.

len


From: Michael Kay [mailto:mike@saxonica.com] 
 
> I do believe that the document paradigm is the best one for 
> the web for this reason and a number of other ones and I 
> think that fat client applications should remain a niche in 
> the web rather than the other way round. 

I certainly think the paradigm of sending a document is a nice and simple
one, and highly extensible to allow the document to contain various kinds 
of
active content in the cases where that's needed. (I also think it would 
have
been nice if it were more symmetric - sending documents in both 
directions.)

I do have some sympathy with the notion - paraphrasing Norm - that if 
you're
going to send a document to the browser, every string of Unicode 
characters
should be a valid document with a defined interpretation. I don't think
that's loosening the standards, it's tightening them - in the past with 
HTML
a subset of documents had a defined behaviour and the rest were displayed
however the browser chose. It doesn't stop authors who want to use a
stricter syntax with potential for error checking and validation from 
doing
that, but it does mean that the amateurs who churn out junk are going to
have their junk displayed the same way by every browser, which seems a 
step
forward from having every browser display it differently.

This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the sender. This 
message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail.

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php


This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.