Lists Home |
Date Index |
- From: "Ogievetsky, Nikita" <email@example.com>
- To: "'firstname.lastname@example.org'" <email@example.com>
- Date: Thu, 14 Jan 1999 12:26:52 -0500
If we just could supply XML text element with datatype attribute,
<DONT dt:type="cdata">&<this tag is not parsed>&</DONT>
- equivalent to CDATA within <DONT> element but easier to read.
I would even declare it in DTD for some elements. For example for those
>From: David LeBlanc <firstname.lastname@example.org>
>Date: Sat, 06 Feb 1999 17:09:01 -0800
>Subject: Re: XML - NG
>Ok, I see I misspoke myself out of not understanding some things that have
>been pointed out about the various meanings of CDATA. I never whould have
>realized (well, not anytime soon), that attribute CDATA wasn't the same as
>other types of CDATA. Thanks.
>What I would like is a content type (call it UPDATA), that has a distinct
>start and stop tag (<UPDATA> ..... </UPDATA>) that is entirely unparsed.
>This would be useful for content that has lots of significant characters..
>like xml itself. In fact, I was thinking that it could be <CDATA>....
></CDATA>, but I now realize that there's a lot of freight attached to that
>character combination :-).
>It seems blechy to have to declare content PCDATA and then do the <[CDATA[
>... ]]> thing in the document. It forces the author of a document rather
>then the designer of a document class to be responsible for "escaping"
>At 07:27 PM 1/13/99 -0400, Steve DeRose wrote:
>>At 3:45 AM -0400 2/6/99, David LeBlanc wrote:
>>>At a minimum, a couple of things i'd like to see are CDATA element
>>>and CDATA attribute content.
>>CDATA element content was one of the most-hated features of SGML (mainly
>>because of the rules about how they end). But more importantly, adding it
>>would remove one of the most important advantages (to my mind) of XML: you
>>could no longer correctly parse a document without the DTD -- since you'd
>>never know whether that "<" you just found was a delimiter or data. I
>>discuss this at length in The SGML FAQ Book, along with the rationale that
>>ultimately underlies many of XML's other choices (probably should have put
>>"XML" in the title, since most of it talks about XML motivation anyway).
>>As for CDATA attributes, I thought we had those. Now, "CDATA" for
>>attributes doesn't mean "entities aren't recognized" in them -- but it
>>doesn't mean that in SGML either. So if that's what you were hoping for,
>>there's no way to get it without pitching the nice property that XML is an
>>SGML subset -- SGML has no way to suppress delimiter recognition in
>>attributes (except perhaps the MS[IOS]CHAR function characters, which I
>>have never seen used, and doubt most SGML implementations actually
>>Just my $0.02.
>>Chief Scientist, Scholarly Technology Group, and
>> Adjunct Associate Professor, Brown University;
>>Chief Scientist, Inso Corporation
>>xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
>>Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
>>To (un)subscribe, mailto:firstname.lastname@example.org the following message;
>>To subscribe to the digests, mailto:email@example.com the following
>>List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)