[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: URIs, names and well known RDDL names, was: Re: Quick edit

  • From: Jason Diamond <jason@i...>
  • To: "Henry S. Thompson" <ht@c...>,John Aldridge <john.aldridge@i...>
  • Date: Wed, 10 Jan 2001 09:00:21 -0800

RE: URIs
> 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
> strategy:

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
function:

GetResourceByRole(rddl, role)

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
this function:

GetResourceByArcrole(rddl, arcrole)

(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? ;-)

Thanks,
Jason.


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.