- From: Brian McBride <bwm@hplb.hpl.hp.com>
- Date: Sat, 14 Jul 2001 15:38:29 +0100
- To: Jeremy Carroll <jjc@hplb.hpl.hp.com>
- CC: www-rdf-interest@w3.org
Jeremy, Jeremy Carroll wrote: > > rdf:li AND rdf:_1 AS TYPES (reserving rdf: namespace) > ========================== > rdf-containers-syntax-vs-schema/test005.rdf explicitly allows rdf:li and > rdf:_1 to be types. > > <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" > xmlns:foo="http://foo/"> > <rdf:_1/> > <rdf:li/> > <rdf:li/> > </rdf:RDF> This is a bizarre corner case where the WG defined the equivalent triples primarily to make sure an answer was defined. There was a choice between making it illegal and allowing it. It's a marginal call. There were no particularly strong reasons for going one way or the other. I don't believe the answer selected contradicts the paragraph from m&s quoted below. rdf:li and rdf:_nnn are names recognised by an RDF 1.0 parser. They represent properties which are resources. They can therefore appear as the subject or object of a triple. One of the things we have to deal with is that we don't have a processing model for RDF. We don't have an architecture which specifies what a parser is supposed to do, what an RDF Schema validator is supposed to do etc. Is type checking a job for the parser or some other component of the processing model? We have taken the view it should be possible to parse RDF and determine what triples an RDF/XML document represents without doing any RDF Schema processing. Consequently we don't expect a parser to determine whether a name represents a type or not to determine whether it can legally appear as a typed node. It might be a real good idea though, for a parser to emit a warning in such cases. If you see some specific problems with this resolution, the WG would be only too happy to learn of them. > > In contrast, in rdfcore/rdf-ns-prefix-confusion/test08.rdf the > rdf:aboutEachPrefix attribute is ignored. Let me get back to you on that one. That test case was generated before we decided to drop aboutEachPrefix and may be in need of revising. > > Could you clarify what the correct processing of things from the rdf: > namespace is when they are not recognised or do not make sense. > > The original spec gave clear instructions: > > 'When an RDF processor encounters an XML element or attribute name that > is declared to be from a namespace whose name begins with the string > "http://www.w3.org/TR/REC-rdf-syntax" [SIC] and the processor does not > recognize the semantics of that name then the processor is required to > skip (i.e., generate no tuples for) the entire XML element, including > its content, whose name is unrecognized or that has an attribute whose > name is unrecognized.' The WG has not considered changing this nor does it have any plans to consider changing it. > > In contrast, the intent of the Working Group seems to be that an RDF > processor should treat an unrecognised or not understood Qname from > rdf:XXX just like it would treat any other Qname (e.g. as a type or a > property). So that now rdf:aboutEachPrefix must be specially recognised > in order to be ignored! As I say, we should look at that test case again. > > I suggest that the original spec is a better intent - the rdf:XXX space > is reserved. It might be better to skip only the attribute in the case > of an unrecognised attribute; but I note that when a non-aboutEachPrefix > supporting processor meets and rdf:aboutEachPrefix attribute the > original behaviour of skipping the whole element is a good one. > > I will give a few more corner cases: > <rdf:Description rdf:li="the only way to give an rdf:li value"/> rdf:li is not allowed as an attribute as specified in test case http://www.w3.org/2000/10/rdf-tests/rdfcore/rdf-containers-syntax-vs-schema/error001.rdf > & what about > > <rdf:Description rdf:Description="text string"/> > > whereas presumably the insanely equivalent > > <rdf:Description> > <rdf:Description>text string</rdf:Description> > </rdf:Description> > > is still an error. I'm not sure what to make of the reference to insanity here. I personally would say they were both errors. I'll refer these test cases to the WG so we make sure the result is clearly defined. There are more too, e.g. <rdf:Description> <rdf:Bag>this one is really silly</rdf:Bag> </rdf:Description> On a minor process point, this is the sort of thing that is probably best sent to www-rdf-comments@w3.org. Thanks for the input. Brian
Received on Saturday, 14 July 2001 10:40:57 UTC