RDF not conforming to the Namespace spec?

[Didier PH Martin]

Hi

<YourComment>
Okay, so your agent is reading the document.  It runs into an element
in another RDF namespace.  You want to use that namespace's URI component
to read in additional schema information.

Two problems:  1) namespace URIs don't necessarily point to schemas, and
2) if they did, you'd be extending the schema mechanism in a way that's
incompatible with DTDs, as they're normally defined and understood.

I don't know if its possible, from an implementation standpoint, to add
the DTD after you've already started parsing the document.  And if you to
could, whether doing so would be reasonable.

Surely this sort of problem has been discussed in the SGML community.
Can someone who has hashed all the details out already perhaps post with
some commentary?
</YourComment>

<Reply>
You're right on this.

For RDF the validation mechanism is not on the name space. The name space
mechanism form the receiver point of view is to be seen as a way to prevent
name collision in the same document space (including document linked to the
document). A simple parser could then process the complete markup name as a
whole word (i.e.. MySameSpace:MymarkupName). It could occur however that two
name space would collide (i.e. two name space have the same name space id
and the same markup name) then in this case, the parser may not take any
chance and replace the name space ID by the URI (if the URI is unique) and
be sure that now the element name is unique (i.e. <uri>:MyMarkupName). The
whole thing is to be sure that we do not have name collision in the document
name space (I mean here the document complete set of names).

For RDF the property list is defined by a schema. RDF is like directory
service schemas.

a) you have to define a record or property set with a schema. You also
define entities relationship with the schema.

The parser do not have to use a DTD as a validation mechanism just the trick
to replace the name space ID by the URI if we want to reduce name collision
to near zero probability. However this is not a validation mechanism this is
a name space collision resolution mechanism like for instance used in
languages like C++ (practically, you replace the name space ID by the URI to
create a unique name element, not more not less -> MyNSID:MyElementName into
http://www.netfolder.com/:MyElementName This is now a very low probability
that a linked document would contain the same named element.)

This is for the parsing side. Now for the interpretation side, a RDF
interpreter (that uses a XML parser) has to know the object's property set
to do something on it. This something could be to build a "frame" for this
object. A frame, to recall, is like a record. This frame could be strongly
typed by a schema that says what the frame is allowed to contain and what
relationship it has with other frames. A schema is not a DTD because the
validation is not at the syntax level but at the interpretation level. Let's
take an example:

we want to import data into a directory service and to do so, we use RDF. To
be sure that the XML parser won't have any name collision we could use name
space otherwise if the document name space is controlled the usage of name
spaces is superfluous. Thus let have a directory record for a user on a
network.

<user>
	<Firstname> Albert </Firstname>
	<Lastname> Einstein </Lastname>
			etc....
</user>

The XML parser has enough to do its job but the RDF interpreter now needs to
know what is the "frame" schema or object category constraints. Thus, the
RDF interpreter can ask the XML parser to parse the xml based schema
document to know the "frame" constraints. After the parsing done, it can
compare each frame property with the schema to know if the "frame" is valid
of not. It could also add a new schema to the directory service if the
object category is new to the directory.

Conclusion: The schema stuff is useful for the interpreter not the syntax
parser which in this case is the XML parser. We have to keep in mind that
XML is for the syntax and other mechanism may have to be provided to the
syntax parser client: the interpreter. A RDF interpreter then use XML parser
to convert into a structure than could be manipulated by the parser:
a) the RDF document
b) the schemas
then "interpret" what to like for instance import data into a directory
service.

A XML document is like a sleeping beauty without an interpreter :-)
</Reply>

Regards
Didier PH Martin
mailto:martind at netfolder.com
http://www.netfolder.com


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)