[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: painting types

• From: "Bullard, Claude L (Len)" <clbullar@i...>
• To: "Simon St.Laurent" <simonstl@s...>, xml-dev@l...
• Date: Tue, 06 Mar 2001 11:50:06 -0600

But it also clearly points to the true limits 
or minimalism of XML's victory.  XML depends 
at it's base on lexical unification; not 
infosets, but syntax.  So your first proposal 
to solve the type problem involves using a different 
syntax (not XML parsable, so not XML) to 
create something akin to architectural forms 
thus breaking the tie to XML by tieing it to CSS.

Who wins?  All you suggest is to move the choice 
to a different means controlled by a different 
means of choosing.  Now instead of Bray, it's Bos.
To quote Goldfarb: "They want to own the parse."

Nodes is nodes.  Properties is propeties.  MMTT.

Len 
http://www.mp3.com/LenBullard

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h


-----Original Message-----
From: Simon St.Laurent [mailto:simonstl@s...]

CSS already uses a 'painting' approach with formatting, and RDF seems 
capable of doing similar things as metadata.

I can't say that I would mind seeing something like:

invoice {type:invoice;}
invoice invoiceNum {type:integer;}
invoice date {type:date;}
invoice item {type:item;}

to use ad hoc CSS syntax as I sit here at a payphone on a 7.2bps connection.

Seems like there'd be a lot of room to run with this, and it could be 
genuinely useful in a wide variety of cases.

• Prev by Date: Re: XQuery - Why is the Charter secret?
• Next by Date: Re: XML Schemas: Best Practices
• Previous by thread: Re: painting types
• Next by thread: re: painting types
• Index(es):
  • Date
  • Thread