[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: URIs, names and well known RDDL names, was: Re: Quick edit
- From: Jason Diamond <email@example.com>
- To: "Henry S. Thompson" <firstname.lastname@example.org>,John Aldridge <email@example.com>
- Date: Wed, 10 Jan 2001 09:00:21 -0800
> and in many cases we only care
> about the values of variables of a particular type. So we establish a
> convention that we will name our variables using the following
I'm glad that this analogy was brought up. Despite its flaws, it helped me
spot a potential ambiguity with RDDL (that I hope isn't as flawed).
Are we sure that we only care about variables (resources) of a particular
type when dealing with RDDL?
Going back to Jonathan's example: What if there were two schema resources
defined in a directory? One's function (arcrole) was for editing and the
other was for runtime validation. We were probably all thinking of the W3C's
XML Schemas when he wrote that but it's entirely possible that either
"schema" could be DTD, Relax, Schematron, or even a TREX pattern.
When thinking in terms of stylesheets, it's even more reasonable to assume
that multiple "style" arcroles could reference resources with different
roles (either CSS or XSL).
To help make things more concrete in my mind, I'm imagining an extremely
simplified API (not that I think the spec should dicatate any specific
implementation--although an RDDL infoset might be something to think about).
If we want to lookup a resource by it's type (role), we'd use the following
If there were multiple resources with the same role, this function could
return either the first one, last one, or all of them. In order to help
disambiguate this function we'd use the following instead:
GetResource(rddl, role, arcrole)
This implies that we want a specific type of resource. I think we should
allow RDDL processors to be a little more flexible.
So when we only care about a a resource's function (arcrole) and expect
we'll know how to process it regardless of it's type (role), we would use
(I realize that it's possible to have used the second function for all three
cases and passing in null for the role or arcrole you didn't want to match
but that's not important--this isn't a real API.)
For all three functions, it's possible for multiple resources to be
returned. So my questions are:
Should xlink:arcrole be required? The third function's usefulness would be
diminished if it was optional.
Should the xlink:role/xlink:arcrole pair (assuming arcrole is not optional)
be required to be unique in a given RDDL document? Using the second function
isn't as reassuring as it could be since it could still return multiple
resources if the pair wasn't required to be unique. (And for bonus points,
is there a schema language currently available that can validate this
requirement or should we invent a new one? ;-)