ISSUE-31 (XSD defined datatypes)

I'm concerned that we're overlooking the obvious in defining references to externally defined datatypes. A solution to external references not mentioned in http://www.w3.org/TR/swbp-xsch-datatypes/ is to use the existing type name as defined within the schema target namespace.

The following schema fragment uniquely defines the global, named type 'adultAge' in the namespace ="http://example.org/ns". SCDs introduce a lot of complexity so that locally defined components can be addressed. However, I don't see the need to address anonymous, locally declared datatypes. Neither does the SCD refer to the type; it refers to the schema component that forms the type definition.

<xs:schema
  targetNamespace="http://example.org/ns"
  elementFormDefault="qualified"
  xmlns:egn="http://example.org/ns"
  xmlns:xs="http://www.w3.org/2001/XMLSchema">
  <xs:simpleType name="adultAge">
   ...
  </xs:simpleType>
     ...
</xs:schema>

The name uniquely identifies the (global) type within the namespace (where available). I think it's undesirable to force users to add IDs to their legacy XML schema. We have use-cases where we create OWL ontologies that re-use existing XML schema datatypes that would be difficult to change retrospectively. Also, the ID doesn't really identify a type, but an XML element.

We can't of course, obtain a datatype URI directly from this (by appending the name to the namespace). XML schema types have their own symbol space distinct from attributes, elements, attributeGroups, modelGroups and notations. I don't think the ontology should be in the business of forcing a canonical URI on the ontologist - all we have to do is identify the type (it's namespace, name pair define a key within the space of types).

The real problem is to identify the schema from the target namespace, so is similar to the import problem, especially where the schema has no namespace.

In addition, SCDs like http://example.org/simpleTypes#xmlns(egn=http://example.org/ns)xscd(/type::egn:adultAge) can't be summarised as QNames because the local part is not a well-formed NCName.

Steve.

Received on Friday, 7 December 2007 17:16:33 UTC