OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

entity-resolution message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: URI mapping (admittedly out of scope) [was: Catalog Requirements]


At 16:39 2000 11 16 -0800, Terry Allen wrote:
>I accept your argument that URI>URI mapping is out of scope for
>this TC, so I won't press the point. 

Okay.

>Do you have one on the question I raised:
| >What piece of what processor would we like it to be, and should
| >the mapping be done before or after the xmlcat is consulted,
| >or both?  and should the two items (URI map and xmlcat) be
| >consulted by the XML processor or by some new, specialized
| >processor that feeds its results into the XML processor?

I think URI mapping is a lower layer than entity resolution--but
higher than redirection--and must therefore happen after xmlcat.  
So I would see the catalog resolution we are defining happening 
first, and that would result in what--in terms of the BNF given 
in RFC 2396 [1] section 4--would match:
  absoluteURI [ "#" fragment ]
(see section 3 for the BNF defn of absoluteURI).

Then, any URI mapping could then occur driven by whatever
map-definition file and mapping algorithm you care to posit.

Then, the resulting URI would be used per whatever its scheme
defines--which might include some kind of redirection and/or
content negotiation.  After all this, you would finally have
some resource's entity body returned to your application.

And the final URI actually used to retrieve this result is
used as the base URI against which to resolve any relative
URI references found in that entity body (again per 2396).

paul

[1] ftp://ftp.ietf.org/rfc/rfc2396.txt



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC