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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   XML - NG

[ Lists Home | Date Index | Thread Index ]
  • From: "Ogievetsky, Nikita" <nikita.ogievetsky@csfb.com>
  • To: "'xml-dev@ic.ac.uk'" <xml-dev@ic.ac.uk>
  • Date: Thu, 14 Jan 1999 12:26:52 -0500

If we just could supply XML text element with datatype attribute, 
something like...
<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
holding URL.

Nikita Ogievetsky

>From: David LeBlanc <whisper@accessone.com>
>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"
>content.
>
>Dave LeBlanc
>
>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
content
>>>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
>>implement).
>>
>>Just my $0.02.
>>
>>Steve
>>
>>
>>Steven_DeRose@Brown.edu; http://www.stg.brown.edu/~sjd
>>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: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)
>>


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