← Prev in month
← Prev in thread
Next in thread →
Next in month →
XPackage location (was: proposal to document the target namespace of a RDDL document)
Michael, ----- Original Message ----- From: "Michael Brennan" <> To: "'Eric van der Vlist'" <>; <> 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
← Prev in month
← Prev in thread
Next in thread →
Next in month →