RE: reftype (IDREF constraints)

Robin Cover wrote:
>> So: are any of the new specs addressing the
>> matter of constraints upon referenced elements?
>> In current syntax, this would amount to saying
>> that IDREF(s) in a given case could only be
>> pointers to specified (classes of) GIs, as
>> approximately in the HyTime 'reftype'.

I don't know of any.

>> Where would/should this concern for scope
>> (semantics) be addressed in the W3C drafts?
>> Are there any dramatic proposals in the works
>> for bedrock re-design, or improvement of the
>> ID - IDREF mechanism?

I'm thinking schema datatypes would be a good place for part of it, if it
should be done.  You could allow the definition of facet on a datatype
derived from uri or idref to constrain the possible targets and then use the
datatype on the linking attribute.

Something like:

<schema>
	<datatype name="uriToSomeElement">
		<basetype name="uri"/>
		<!-- some representation of a 
			constraining facet on the datatype, just making this
up  -->
		<constraint>
			<elementTypeRef name="SomeElement"/>
		</constraint>
	</datatype>

	<elementType name="SomeElement">
		<attrDecl name="id">
			<datatypeRef name="id"/>
		</attrDecl>
	</elementType>

	<elementType name="OtherElement">
		<attrDecl name="someElement">
			<datatypeRef name="uriToSomeElement"/>
		</attrDecl>
	</elementType>
</schema>

In the case of URIs, you could only express an intention as to what is on
the other side of the URI.  On an IDREF, the processor could determine if it
matched the facets.  The facets would have to allow a match to one or more
elementType's in the current schema or declared namespaces, one or more
elementTypes defined in a specific DTD or ad-hoc elements, mime types (if it
is a uri to a JPEG for instance), maybe others.  Again, I'm not sure it
should be done, but that is where I think it might fit best.

I'm really interested in seeing what the W3C Schema group has in store for
their next draft (as I'm sure most everybody on this list is.)

Received on Tuesday, 27 July 1999 20:39:11 UTC