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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: Last minute request for BASE64 section support in XML 1.0

[ Lists Home | Date Index | Thread Index ]
  • From: "Don Park" <donpark@quake.net>
  • To: "David G. Durand" <dgd@cs.bu.edu>, <xml-dev@ic.ac.uk>
  • Date: Tue, 10 Feb 1998 12:45:17 -0800

David,

>This is silly. The specific proposal (a BASE64 marked section) _can't
>be_ added at this point under the rules of the W3C. It's also unlikely
>to fly in XML 1.1 for two reasons (which are more substantial
>technical problems with the proposal as it stands):


Form and timing of the proposal might be silly, the need is not.

>  1. The proposed syntax is not compatible with SGML syntax, and can't
>be made compatible without changes in SGML (violating the goals of the
>XML project).


Agreed.  I am not a SGML whiz and I count on folks like you to point out
problems.

>  2. The effect desired can be easily obtained in XML by the use of
>NOTATION.


Notation declarations have no use for non-validating applications.  IMHO,
most applications will validate only during design time and never during
runtime.  Unless some means independent of DTD must be used to indicate that
content is encoded form of some binary data.

>If you don't like notation, you can even just use an attribute value
>and keyword and skip the notation declaration. I don't remember the
>character repertoire of BASE64, but the fact that it's email safe
>means that the escaping issues are certainly no harer than those for
>any XML text content.


I am not really concerned about how binary data is encoded in individual XML
format.  I am concerned about the lack of support in the standard.  As Tim
Bray suggests, I am trying to put in place a recommended convention for
embedding encoded data so we can all readily store and retrieve binary data.

Currently, I am proposing to add two reserved attributes

xml:content-encoding="base64;second-encoding-layer;third-encoding-layer"
xml:content-type="mime/type"

Multiple names in the encoding attribute might be going overboard but I am
just thinking ahead of multilayer encoding.  Such scheme could be used to
embedded compressed XML document within another XML document.  Should the
compressed XML document be expanded inplace and fed into the parser?  Hmm.
Looks like there will be two levels to the proposal.

Your mention of notation brings up a possible need of xml:content-notation
attribute which could be used by other elements to reference the binary
data.  Since referenced embeded data must be defined before the first
reference, placements becomes rather restricting especially if the embedded
data element is not significant at the point of definition (where icon is
stored inside an XML file is not important but where it is referenced is).

I appreciates your comments.

Regards,

Don Park
http://www.quake.net/~donpark/index.html




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