XObjects (was TLAa was SOX)

[Bill la Forge]

From: Peter Murray-Rust <peter at ursus.demon.co.uk>

>At 10:09 08/10/98 -0700, David Brownell wrote:
>>I believe we need two modes of document creation:  "empty",
>>so they can be constructed programmatically; and "parsed",
>>where they're built from a stream of XML text.
>
>I agree completely. I found I needed something this while I was
>constructing my subclasses of ElementNode (I call it XNode in JUMBO). So we
>also have to consider it for ElementNodes.


I agree as well. DomBuilder needs a second method for building an empty
document.

>Typically I find the following modes of operation:
> - read in a complete XML file and construct the subclassed ElementNodes at
>document creation. This may involve special storage, validation, inter
>Element relationships, etc.
> - create an empty tree. build on empty nodes. then create the node
>internals. This must then be strictly compatible with the DTD (if any).
>Help in regulating this would be useful :-)
> - read in (or create) a tree with non-empty elements and then modify these
>interactively (edit). This is similar to the last operation but might
>require additional support.


This is where something like XSchema could play a big role.
A particular instance of DomBuilder should be bound to a single
XSchema. If we have a DomBuilder that can handle XSchema's for editing,
then the resulting editing-specific DOM tree should have
pleanty of methods available for assisting.

>>
>>The structure of such a builder is a tricky problem.  I
>>think of it as a module that's separate from the DOM and
>>separate from the (SAX) parser, but might need to be coupled
>>to either or to both.  Reason:  neither API is sufficient
>>for supporting all DOM semantics without some more coupling.
>>
>>Example: fully conforming to DOM means having access to more
>>information than SAX exposes.  Which attributes were defaulted?
>>What are the default values of attributes?  Where do entities
>>start/stop?  What parsed entities exist?  And more.  While
>>it's easy to write a builder that takes a SAX event stream
>>and a document, then populates a DOM Document from it, it can't
>>possibly offer full DOM semantics.  (Then there's efficiency...)
>
>We always knew that SAX was an 80/20 solution. It seems we have the
>following options:
> - ignore those bits that SAX doesn't manage at present. At least this
>gives us a working system (and you can see how keen I am on working
>systems...) For the sort of thing I do, entities, default attributes etc.
>are not essential. Maybe I'm being selfish... But I'd hate us to spend
>months discussing what we should put in.
> - extend SAX so it does (al)most what we want. I can't comment.
> - base everything on DOM. Do we have enough stuff in DOM 1.0 and do we
>have sufficient XML parsers interfaced to DOM? [I'm rather ignorant here].


We can also get this information in the back door (as given above).
But now I see a chicken/egg problem: What about those cases when
we don't know before hand the applicable markup language? In that case
the DomBuilder will need to handle all posibilities. Or is it reasonable
to pre-parse?

Bill


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)