RE: Request for Comments: XML binary encoding

["Al B. Snell" <alaric@alaric-snell.com>]

On Mon, 9 Apr 2001, Danny Ayers wrote:

> In what order will the elements be delivered? I'm guessing the transfer
> would be most efficient if structure was sent first then data, but this
> would screw up SAX-like event driven interfaces that work on the elements in
> doc order. If you weren't careful, the overhead of emulating SAX could set
> you back at square one. Also worth bearing in mind is that SAX doesn't keep
> an in-memory model, so the data stream can be arbitrarily long :
> structure-data might cause problems. structure-data-structure-data... ???

Is there a good reason to do other than:

SYMBOL("...URI of XHTML namespace gets assigned symbol ID 1")
SYMBOL("...URI of CIE XYZ color space gets assigned symbol ID 2")
SYMBOL("...URI of XML Adaption Layer namespace, gets symbol ID 3")

STARTINTERNALENTITY
 STRING("This is an internal entity containing a string. It gets entity ID 1")
ENDINTERNALENTITY

EXTERNALENTITY("http://a-uri/gets-entity-ID-2")

STARTELEMENT(3,"xml")
 STARTATTRIBUTE(3,"version")
  STRING("1.0")
 ENDATTRIBUTE
 STARTELEMENT(1,"html")
  STARTELEMENT(1,"head")
   STARTELEMENT(1,"title")
    STRING("Alaric's Zany Page")
   ENDELEMENT
  ENDELEMENT
  STARTELEMENT(1,"body")
   STARTATTRIBUTE(1,"color")
    COLOR(2,"0.5,0.5,0.5")       
   ENDATTRIBUTE
   STARTELEMENT(1,"p")
    STRING("This is some ")
    STARTELEMENT(1,"em")
     STRING("emphasised")
    ENDELEMENT
    STRING(" text. Here is the content of an entity:")
    ENTITY(1)
    STRING("...and here's the content of an external parsed entity:")
    ENTITY(2)
   ENDELEMENT
  ENDELEMENT
 ENDELEMENT
ENDELEMENT

 - that's what I was thinking of. Document order preserved.

Note that the attributes could contain arbitary markup, not just
atomic data types, although this facility would not be used for standard
XML.

Note the use of symbols to avoid repeating the namespace URIs for elements
and color spaces.

> I haven't a copy of the spec at hand - in which part of the DOM is the bit
> about elements being string based?

Hrm... there are string nodes and not (say) integer or date or color or
boolean nodes. They could be added.

> Some use cases would help - e.g. how you would replace an existing SOAP
> transport.

Yep. And stuff about applications. Ideally this would be sucked into
existing DOM/SAX implementations so they recognise incoming data in this
format and transparently handle it as XML if the application uses the
standard SAX/DOM interfaces; or if the application requests the enhanced
stuff, it would be given the enhanced interfaces, and standard XML
documents would be presented to it wrapped in an XAL "xml" element as
shown above... this transparent trivial translation within XML libraries
would ease adoption, but it needs to be made explicit to prevent people
becoming scared (you know what *humans* are like about new things).

> One last random though - what the 2-channel kludge? First channel provides
> schema in XML format, 2nd channel provides data as specified. (I think this
> same principle came up a while ago, with the schema being sent first)

Yeah; it's less useful for small messages such as SOAP, though, where the
schema may end up bigger than the data itself - the complexity of the
parser required wouldn't be justified there...

Reminds me. Processing instructions. Apart from <?xml ... ?>, is anybody
actually using these? What for? How about putting them in namespaces? I'm
wondering about an <?include "URI"?> PI to replace external entity
references (which I hate). But there's no mechanism for standardising
PIs. Their exact purpose isn't really specified...

> Danny Ayers
> http://www.isacat.net

ABS

-- 
                               Alaric B. Snell
 http://www.alaric-snell.com/  http://RFC.net/  http://www.warhead.org.uk/
   Any sufficiently advanced technology can be emulated in software