[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Linking and Query question
At 09:54 AM 8/5/97 -0700, Andrew Layman wrote: >Can I create a link that, in effect, contains a query so that it >references one document among a set? For example, if I know that several >versions of a document exist, and I want to reference the latest >version, but I'm willing to accept either of the two prior versions, can >I express that? If so, how? Thanks. If the reference to a document is via an entity reference, the query can be part of the system ID for the document. As system IDs in XML are always URLs, if you have a way of expressing the query in an URL, you can do it that way. If not, then the short answer is "no" (unless there's some aspect of URLs or TEI extended pointers I've overlooked, which it quite possible). In a general SGML system, there are three basic approaches: 1. Define your own application-specific addressing syntax and semantics and use it, hoping tools will support it or providing your own support (because the scope of use is totally within your control). 2. Use Formal System Identifiers and make the query part of an entity's system ID. 3. Use query addressing and make the query part of a direct or indirect address (that does not use a declared entity). The only difference between these three approaches is that two and three are done within the framework of standardized definitional mechanisms defined by ISO/IEC 10744:1997 while one is not. In all three cases you still have to implement support for the query and provide the necessary integration with the tools you're using (browser to repository, editor to repository, etc.). The Formal System Identifier Definition Requirements (FSIDR) facility of ISO/IEC 10744:1997 (Annex A.6, reviewable at http://www.drmacro.com/hythtml/clause-A.6.html) provides a syntax for associating repository-specific attributes with system IDs. For example, say you have a repository with a "version" property for storage objects. You can refer to this property by declaring the repository as a "storage manager" and providing an attribute (or attributes) for specifying the version you want, something like this: <!-- Use "FSISM" PI to identify the names of storage manager notations: --> <?IS10744 FSISM MyDocManager> <!-- Declare notation for storage manager. Serves to provide local name for repository so generic system can call repository's API or human observer can tell what the repository is. --> <!NOTATION MyDocManager PUBLIC "-//ME//NOTATION FSISM My Document Manager//EN" > <!-- Declare attributes for passing parameters to the repository: --> <!ATTLIST #NOTATION MyDocManager version -- The required version. Syntax is "([<>][=]?)?[0-9]+(\.[0-9]+)?" Prefixes for version number: < Anything less than specified version > Anything greater than specified version <= Anything less than or equal to specified version >= Anything greather than or equal to specified version If no prefix specified, only specified version is used. -- CDATA #IMPLIED -- Default: latest version -- > Obviously, these declarations can be provided by the storage manager provider and used by reference from documents--you wouldn't expect authors to type these things themselves (or even necessarily be aware of their presence or use). You then invoke the storage manager by treating the notation name as an element type name within the system ID: <!ENTITY A-Doc SYSTEM "<MyDocManager version='>1.2'>mydoc.xml" CDATA SGML > As the semantics of the tags within a system ID are well defined by the FSIDR, it is probably reasonable for XML systems to treat the tag name as a repository notation name even when the formal declarations are not present. If the storage manager name is well understood (e.g., "URL"), there's no problem. It's probably also reasonable to assume that storage manager names are generally unique and therefore processing can be associated with the names directly (rather than by requiring a notation declaration with a public ID). This is analogous to being able to map entities by entity name within an SGML Open catalog. A processor would provide a way to associate the storage manager notation MyDocManager with that storage manager's API (i.e., the integrator of the storage manager would register a DLL or DLL entry point with the notation's public identifier). The processor would then pass the value of the version attribute and the data following the MyDocManager start tag to the API. If you're not addressing the document as an entity but using some other query, I don't think XML Link provides a way to do this (because it doesn't generalize the notion of addressing by query). The HyTime architecture does generalize addressing by query such that you can declare a query notation with whatever semantics you want and then use that query. The only requirement is that the result of the query be a list of nodes in groves. In DOM terms this would mean you get back objects conforming to the DOM model, rather than the unparsed data of the document addressed. (All addressing is in terms of the results of parsing, not the unparsed source.) For example, to create and use such a query, you could do something like this: <!-- Declare a notation for my query. The syntax and semantics of this query are presumably documented somewhere. The public ID of the notation should get an observer to this documentation. --> <!NOTATION MyDocQuery PUBLIC "-//ME//NOTATION My Document Query//EN" > <-- Now declare an element type that uses this query notation for addressing: --> <!ELEMENT DocLink -- A hyperlink to another document using a query -- - - (#PCDATA) -- Content is title of document linked to -- > <!ATTLIST DocLink document CDATA #REQUIRED -- Contains query of document to link to -- loctype CDATA #FIXED "document QUERYLOC MyDocQuery" -- Associate referential 'document' attribute with query notation 'MyDocQuery' (uses "reference location address" facility) -- HyTime NAME #FIXED "hylink" -- This is a HyTime hyperlink -- anchrole CDATA #FIXED "refmark document" -- Roles of the anchors of this link. DocLink element is reference mark. -- anchcstr CDATA #FIXED "self required" -- Indicate that the first anchor role (refmark) is a "self anchor", that is played by the link element itself. -- > ... <p>See <doclink document="mydoc.xml[version 1.2+]">My document</doclink>... A HyTime aware processor interprets the above as follows: 1. Sees that Doclink is a hyperlink. Looks for the required (by HyTime) "anchrole" attribute, from which it will determine the names of the attributes used to address the anchors (they are the same as the anchor role names). 2. Sees that "refmark" is a self anchor, so no addressing attribute is needed for it. Sees that second role is "document". Looks for attribute named "document". 3. Finds attribute named "document". Looks for attribute named "loctype" (location type) to see if a location type has been associated with this attribute (without location type, the HyTime engine has no way of knowing what form of addressing is being used [unless the attribute is declared as IDREF(s) or ENTITY/ENTITIES]). 4. Finds a loctype attribute and sees that the document attribute is a query location that uses the notation named "MyDocQuery" 5. Looks to see if a notation named MyDocQuery has been declared. It has. 6. Passes the value of the document attribute to the MyDocQuery API (again, registered using whatever integration API the browser provides). The processor (my document manager in this case), interprets the query and provides a response. 7. Waits until it gets a response, which had better be a list of objects in an object model it understands (e.g, grove nodes, DOM objects, etc.). 8. Assuming it gets a response, enables traversal to the returned objects. XML Link removes the need for the above general processing by providing a fixed set of query notations that XML Link recognizes (URLs and TEI extended pointers). However, this limits your ability to do things these two query notations don't provide for. Note also that the XML Link specification can be defined in terms of the HyTime generalizations such that any general-purpose HyTime engine can process XML Link documents (and you would expect HyTime engines to have built-in support for XML Link so that there would be no additional integration required to process XML Link documents). The HyTime mechanism has no "magic"--it just provides a framework within which the integration you'd have to do in any case can be done. It simply provides a way to name things (queries, storage managers) with universally-unique names (public IDs) and associate these universal names with local names (notation names). This framework standardizes the formal declaration of what you're doing and (hopefully) makes the integration mechanism consistent across tools, which shoudl make integration easier. It doesn't remove the need for tools to be plugged together by humans (either directly or through the definition of API standards like the DOM or CORBA or ODBC). Cheers, Eliot xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@i... the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|