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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   XPackage location (was: proposal to document the target namespace of a R

[ Lists Home | Date Index | Thread Index ]

Michael,

----- Original Message -----
From: "Michael Brennan" <Michael_Brennan@Allegis.com>
To: "'Eric van der Vlist'" <vdv@dyomedea.com>; <xml-dev@lists.xml.org>
Sent: Tuesday, April 02, 2002 3:11 PM
Subject: RE: [xml-dev] RDDL: proposal to document the target namespace of a
RDDL document.


> RDF may fit here, as well, but I tend to lean in favor of linking rather
> than RDF assertions. XLink is much more approachable to most developers
than
> RDF. Also, it's not clear to me how you would support both an arcrole and
> role for a resource locator using RDF -- unless you use an RDF/XLink
> combintation as XPackage does, and XPackage has a rather unweildy syntax
> IMO.

The XPackage syntax for specifying a location is a completely separate (but
interesting, I think) topic, so I've switched subject threads.

We at the Open eBook Forum actually debated for quite a while on the
XPackage syntax for location specification, with a member of the W3C RDF
working group participating. What we finally came up with (and appears in
the current XPackage specification) is actually quite elegant and useful,
and shouldn't be too daunting.

First, in XPackage (and RDF), a resource's unique ID URI usualy is *not* its
location. An book may be identified by rdf:about="urn:isbn:123456789", but
it may have a completely different physical location relative to the
XPackage document file. That physical file location is simple to specify,
using <xpackage:location>:

<xpackage:resource rdf:about="urn:isbn:123456789">
  <xpackage:location xlink:href="book.xml"/>

That doesn't seem too unweildy to me. What's probably unweildy is my
explanation in the XPackage specification of *why* this syntax is used. In
RDF terms, it seems that the book's location itself a location---a separate
level of indirection. It becomes clearer, however, when you think that the
book has a location, and that location has an href as one of its properties.

After all, the book's location might have other modifiers, such as its role.
One convenient role is a "request" role, which XPackage uses to say that
some other resource (such as an HTML document) may *request* this resource
using a different location URI. The following image, stored at "image.png",
may be requested from another document in the package as
"http://mydomain.com/images/flowers.png":

<xpackage:resource rdf:about="urn:examples:image">
  <xpackage:location xlink:href="image.png"/>
  <xpackage:location xlink:href="http://mydomain.com/images/flowers.png";
    xlink:role="http://xpackage.org/xlink/roles/request";
    xpackage:contextResource="urn:examples:document2"/>
  <xpackage:contentType>image/png</xpackage:contentType>
</xpackage:resource>

That would allow multiple HTML documents to access the same image using
different requesting locations.

Referring locations are for expert users, though---for most users, a
resource's location can be specified using <xpackage:location
xlink:href="someLocationURI"/> . As an added benefit, the location is even
XLink compatible!

Cheers,

Garret Wilson
GlobalMentor, Inc.
Member, Open eBook Forum, W3C, Unicode
Editor, XPackage specification: www.xpackage.org






 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS