Re: XML Enriched N-Triples (XENT)

Sean B. Palmer wrote:

> For example, as was noted to me on #rdfig [1], XENT itself is pretty
> much a mix of constructs from Notation3/N-Triples and RDF/XML mashed
> together into one proposal. I tried, of course, to take the best
> features from each approach, but the problem is that proponents of RDF
> serializations are usually very passionately one-sided about which
> method they prefer (talking from my possibly incorrect experience
> here). In other words, people tend to favor one serialization very
> much over the others. So whilst you'd think that a compromise between
> them would be a good idea, it'll probably just end up with almost
> every established member of the RDF community snubbing it :-)

That's not why I'd snub it. I'd snub becuase you're using XML to 
tunnel yet another RDF syntax through element content, instead of 
levaraging XML to create yet another RDF syntax. That strikes me as 
pointless - as I have to write a tokenizer just for the element 
content, I'd rather not have to fire up an XML parser just for the 
sake of getting at it. The XML is redundant.


> There's a lot of FUD surrounding QNames, but at the end of the day
> they just map prefixes to namespaces. For RDF, it's too handy an
> abbreviation mechanism for URIs to pass up. 

Not handy. RDF was a usecase for namespaces.


> The TAG finding says that parsing costs of QNames in PCDATA may be
> high. I've proved that, for Python and SAX and least, the opposite is
> true. 

Agreed. And Qnames in element content have  higher cost (imo).


>>I don't want to build a tokenizer for parsing apostrophes,
>>white spaces, and other strings on top of another tokenizer,
>>the XML processor.
> 
> 
> Why not?

One of them isn't neccessary.

Bill de hÓra

Received on Tuesday, 17 June 2003 15:58:41 UTC