[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Request for Comments: XML binary encoding
- From: Danny Ayers <danny@panlanka.net>
- To: "Al B. Snell" <alaric@alaric-snell.com>,The Deviants <xml-dev@lists.xml.org>
- Date: Mon, 09 Apr 2001 18:46:22 +0600
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... ???
I haven't a copy of the spec at hand - in which part of the DOM is the bit
about elements being string based? Another guess - that it's way back up the
model somewhere, at a layer from which building can be done, without
scrapping the model altogether. I may be wrong.
I believe JDOM is an interesting SAX/DOM hybrid designed for ease of use -
may be worth a look for ideas.
Some use cases would help - e.g. how you would replace an existing SOAP
transport.
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)
---
Danny Ayers
http://www.isacat.net
<- -----Original Message-----
<- From: Al B. Snell [mailto:alaric@alaric-snell.com]
<- Sent: 09 April 2001 16:48
<- To: The Deviants
<- Subject: Request for Comments: XML binary encoding
<-
<-
<-
<- 1) The binary encoding itself, which replaces XML, should be a logical
<- superset. I would suggest that entity declarations can appear at
<- any point
<- (like PIs) and either have scope from that point in the document order
<- onwards, or lexical tree scope in document order within the current node
<- and its children. The format will probably resemble a direct
<- serialisation
<- of a SAX event stream. There will be atoms (strings, numbers, symbols[0],
<- etc)
<-
<- 2) The parser and serialiser will have SAX-like interfaces that do not
<- directly emulate SAX due to the differing underlying representation, but
<- are similar in spirit. There will be two filters between this and SAX -
<- one for reading and one for writing - which embody an "XML adaption
<- layer" on top of the binary encoding to encode the parts of XML that are
<- not directly represented (DOCTYPE declarations, for example - apart from
<- the entity delcarations therein)). I would imagine that the XAL would
<- involve placing the XML document inside a top-level XML element (in the
<- XAL namespace) containing attributes for the XML version number and the
<- <!DOCTYPE ...>, if any.
<-
<- There would be no need for an encoding attribute - UTF-8 all the
<- way, with
<- all character entities expanded so there are no special characters in the
<- strings; they can be processed literally.
<-
<- 3) There would also need to be a DOM replacelement. Existing DOM
<- implementations can be used with the DOM tree built from an XAL SAX
<- wrapper, but to use the advanced beyond-XML features for specialist
<- applications (or, dare I dream, if this thing supercedes text-based XML
<- ;-), a DOM that offers access to the nicer aspects (such as directly
<- accessing numbers rather than the XAL having to convert them to strings
<- which the application then converts back to numbers...) would need to be
<- defined.
<-
<- 4) A catchy name is needed for the above three. netXML, netSAX, netDOM -
<- emphasises the smaller size makes it more suitable for many of the
<- networked applications of XML. XMLplus, SAXplus, DOMplus - also catchy,
<- but isn't there already a DOMplus?
<-
<- I would ideally like to see a standard such as this reach the W3C, but
<- if not, I can submit it as an RFC in some month's time. Until then,
<- discuss...
<-
<- [0]Symbols are oft-used strings that are declared once and then referred
<- to by a number - like my namespace IDs in an earlier proposal:
<-
<- http://lists.xml.org/archives/xml-dev/200104/msg00175.html
<-
<- Symbols are used for entity names, element names, attribute names, and so
<- on.
<-
<- 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
------------------------------------------------------------------
The xml-dev list is sponsored by XML.org, an initiative of OASIS
<http://www.oasis-open.org>
The list archives are at http://lists.xml.org/archives/xml-dev/
To unsubscribe from this elist send a message with the single word
"unsubscribe" in the body to: xml-dev-request@lists.xml.org