W3C home > Mailing lists > Public > xml-uri@w3.org > May 2000

Re: RDF namespace conventions

From: Simon St.Laurent <simonstl@simonstl.com>
Date: Mon, 22 May 2000 12:05:09 -0400
Message-Id: <200005221603.MAA31664@hesketh.net>
To: "Tim Berners-Lee" <timbl@w3.org>, <xml-uri@w3.org>
At 11:51 AM 5/22/00 -0400, Tim Berners-Lee wrote:
>>The needs of the top layer don't necessarily determine the needs of a lower
>>layer.
>
>That is true only to a certain extent.  One of things which does have to be
>consistent
>is identity.  You can't combine a tokenizer and a parser if they have no
>common
>notion about the idenity of a token, thing passed between them.

I think the combination you're making there is one that goes against the
flow of the XML 1.0 spec, which explicitly separates XML parser behavior
from application behavior - XML parsers aren't supposed to know or care
about the 'identity' of the tokens being passed.  That's too much
intelligence for an XML parser, even with namespaces dropped on top. 

(I think you're calling the XML parser a 'tokenizer' and the application
logic the 'parser', but I'm not really certain.)

>In this case the only problem is with relative URIs.  (For use-case in which
>the system breaks with relative URIs and literal comparison see
>http://lists.w3.org/Archives/Public/xml-uri/2000May/0281.html
>)
>
>So, the layer separation you suggest would work only with either
>(a) no relative URIs -- at least a warning that XML lower layers don't grok
>them, or
>(b) change lower layers to absolutize before comparing.
>
>Either of these would be consistent.  The second would be cleaner.

Neither of these is necessary.  You're driving the quest for 'consistency'
too deep into the underlying layers.

XML processing does not require either of these approaches.

Simon St.Laurent
XML Elements of Style / XML: A Primer, 2nd Ed.
Building XML Applications
Inside XML DTDs: Scientific and Technical
Cookies / Sharing Bandwidth
http://www.simonstl.com
Received on Monday, 22 May 2000 12:03:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:32:42 UTC