Cart
|
[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
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:
BaseInfoSetItem
{
// 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?
}
</warning>
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...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
