OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: Binary Data in XML

[ Lists Home | Date Index | Thread Index ]
  • From: ricko <ricko@allette.com.au>
  • To: Tim Bray <tbray@textuality.com>
  • Date: Thu, 01 Oct 1998 02:13:48 +0800

Tim Bray gDG

> Suppose I wrote up a NOTE, should occupy less than one page, proposing
> a reserved attribute xml:packed with, for the moment, only two
> allowed values, "none" and "base64".  The default value is "none".

...

> Are there any gotchas I'm missing?  Don't know if I could persuade
> one of the WGs to take it up, but it seems pretty obvious that there
> is not only industry demand but in fact people doing this already, so
> the case is pretty strong I think. -Tim

I think it would be an excellent idea. Apart from its intrinsic worth,
it should also serve as an exemplar for other WGs of a document
specifying an embedded notation within XML elements. I agree
it should include an FPI for the notation, but I also think it should
make it clear that it notationally it is a post-parse. (And in the
general case, there is no reason why such post-parsing might not
result in element nodes in the result DOM/grove: this would
provide a clear path for other structured languages embedded in
XML: CSS, etc.)

I would guess that anyone interested in having proprietary field
encyption of the content of particular element types would be
interested in such an exemplar.

Is this a schema issue?  Well, I think not, in that I tend to think
of encoding as orthogonal to schemas (in a similar to fashion to
how xml:lang is orthogonal to schemas).

One approach for naming would be to use the HTTP/MIME
header names, where we can.  A PCDATA element type with
some encoded data reveals that there is a class of NDATA entities
which may be too small or frequent in a document to warrant being
stored as external resources.  So it is logical that much of the HTTP/MIME
header information may also be relevent and useful to these "inlined
NDATA entities".

I am not suggesting that all the HTTP/MIME headers need to be duplicated
now; certainly if Tim makes his note, it should be modest. But I
think it probable that over time more HTTP/MIME headers will
be found to be appropriate to add as attributes in this kind of element.

Rick Jelliffe


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





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS