[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XML Information Set Requirements, W3C Note 18-February-1999

  • From: Clark Evans <clark.evans@m...>
  • To: Paul Prescod <paul@p...>
  • Date: Mon, 22 Feb 1999 06:25:27 +0000

push pop xml
Paul Prescod wrote:
| I don't believe that the W3C has forgotten about stream processing. One of
| the more controversial parts of the XML namespace specification is
| intimately tied to stream processing (local namespaces). I think that I
| can safely say that when XML was being developed streaming uses were as
| high in the minds of the working group as tree-based uses. Stream based
| processing has always been more common in the SGML world than tree
| processing. Okay then, why are the DOM and XSL tree based? Well, the web
| infrastructure favors small documents inherently. Large streams must be
| broken up on the server side for performance reasons. Bandwidth, not RAM,
| is the limiting factor in Web user interfaces.

This clears a great deal up for me.  Thank you.  I didn't see 
the direct relationship between usage of XML for stream processing 
and local name spaces.  Thus, a similar controversy would arise 
if one proposed local architectures?  *evil grin* 

Jeff Sussna write:
| If you approach XML as a type system, the concept of document loses
| its first-class status (or at least should, in my opinion).

<warning up-time="34h">

I think I agree with this.  Please correct me, but with Property Sets,
each node has a link directly to the 'document root'.  I see this
as something which deserves consideration (among other things)
when the Infomation Set is defined.   Perhaps it can look like this:

  // stuff common to both stream and object representations 

TreeInfoSetNode public BaseInfoSetItem
  // extra stuff that you get for free when the representation
  // is an in-memory graph, database wrapper, or some other
  // complete object with random access.
  TreeInfoSetNode *DocumentRoot();

EventInfoSetStack public BaseInfoSetItem
  // extra stuff relevant when you have an event based, stack 
  // representation of the information in question.  This would 
  // be the same as the 'visitor' interface for the TreeInfoSet?


Hmm. Just meandering...

Rick Jelliffe replied to Jeff's note:
| XML is not a type system. A document is a graph of elements, data,
| comments and PIs with
|    * an ID namespace
|    * optionally some element type declarations
|    * optionally some entity declarations and notation declarations
|    * optionally namespace declarations which allow local type names to
|      be qualified by a URI
| In other words, the document is the block mechanism for metadata 
| and namespaces for a subtree of the entire hyper-document.

Hmm. Perhaps this would be a good starting place for
the 'definition' of a document.  Thus, would it be fair 
to say that a document is analogous to a database transaction?

If so, then my question becomes:  How can I express nested blocks?  

| XML is a labelling notation, not a type system.

I'm not sure I get the distinction.  When you label 
something arn't you in effect classifying it, i.e.,
giving it a type, and, isn't a label required 
to identify type?  

| If the document loses its first-class status, which of these things
| should be gotten rid of? Do you want arbitrary scoping of IDs, element
| type declarations, entity declarations, notation declarations and
| namespaces?  If so, you need some block mechanism to allow these.  

Hmm.  Well, I see a stream based system having a stack. 

Thus, each <tag> beginning something puts the element 
on the stack, and each </tag> pops the stack.  Thus, I see
<tag> and </tag> as my block mechanisms.   Is this too niave?

Don Park wrote:
| Why not have "from here on use these declarations" as the 
| default behavior and then introduce 'push' and 'pop' constructs? 
| 'push' would save current declaration settings and the 'pop' would 
| just restore to the saved settings.

Mabye I'm not getting it, but <tag> and </tag> provide the
push/pop mechanism automagically.  The only things that have
problems is those "from here on" things.  It's unfortunate
that SGML backwards compatibility dictate that this is the
default behavior... and thus <tag> </tag> can't provide
the push/pop mechanism?  *dazed*

I think I need to go back and do more real-world hacking, I'm 
starting to get a better felling for XML.  Sorry for butting in 
the conversation again.

:) Clark Evans

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)


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.
First Name
Last Name
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.