[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XLink comment and queries
At 02:11 PM 4/23/98 -0400, Daniel Pitti wrote: >Thus, in trying to XMLize an existing SGML DTD, I find myself wanting my >linking elements to have both idref/s and entity/ies for use in creation >and maintenance, and XLink attributes for exporting the same, the latter be >created at the time of exporting. Is this sensible at this juncture? Or am >I overlooking something? In a previous note, I mentioned that the HyTime architecture provides a syntax for declaring what form of addressing is being used in a given instance. This facility lets you be 100% clear about how to interpret the values of attributes that you know are referential, lets generalized software manage documents that use a variety of addressing methods, and makes it clearer that single element types can use a variety of addressing methods. The facility is the "reference location address" (refloc) facility (clause 7.8). It provides two attributes that can be used on any element: - loctype (location type), which associates referential attributes with their addressing methods (notations) - rflocsrc (reference location source), which associates pairs of referential attributes to indicate that one attribute addresses the location source for the other (e.g., book= and refid= as often used with DynaText). With these two attributes, you can completely characterize the referential attributes used by a given element such that a generalized system that implements the refloc facility and implements the addressing methods used will be able to resolve the addresses. XLink doesn't need to provide such a mechanism because it requires the use of exactly one addressing method: URIs and XPointers. However, in an environment where you want more flexibility you do need this sort of facility. For example, a generic linking element that can use any form of addressing, including, but not limited to, XPointers, can be declared like so: <!-- Declaration for a generic linking element --> <!-- NOTE: Because this is intended for authoring, it uses SGML features not allowed in XML. Use of the refloc facility does not require any SGML-only facilities, but here they are used for convenience. --> <!-- Declare use of HyTime architecture so we know what semantic domain defines the meaning of the loctype attribute. --> <?IS10744:arch name="HyTime" public-id="ISO/IEC 10744:1997//NOTATION Hypermedia/Time-based Structuring Language (HyTime)//EN" > <!-- Declare a hyperlink element type: --> <!ATTLIST GenericLink href -- Referential attribute, points to other anchor (resource) of link. -- CDATA #REQUIRED linktype NAME "crossref" -- Default link type name -- loctype CDATA #FIXED "href IDLOC" -- href attribute is interpreted as an ID reference -- HyTime NAME #FIXED "hybrid" -- Must be mapped to some element type in HyTime architecture. Here hybrid is used for implicity. -- > The value of the loctype attribute is a list of tupples (either pairs or triples depending) where the first token is an attribute name, the second token is a location type keyword as defined by the HyTime architecture, and the third token, if required is a notation name (as shown in the next example). Thus, this value of the loctype attribute declares the href attribute to be, semantically, an "IDLOC", which means that the attribute is interpreted as though it had a value prescription of "IDREF" or "IDREFS". Other choices are "ENTLOC" (entity references), "TREELOC", (tree location address), and so on, corresponding to the build-in addressing methods of HyTime. You can also refer to non-HyTime-defined addressing methods, as shown below. [Note that here the HyTime architecture is being used *only* for the loctype attribute. The GenericLink element is not declared as a HyTime hyperlink. This is an example of using an architecture that provides a "global" attribute. The "hybrid" element form is HyTime's generic element that has no meaning other than HyTime-specific processing will be applied. Thus any element can be mapped to the hybrid form in order to associate it with the generic facilities of the HyTime architecture, such as the loctype attribute. You can also use this technique to characterize attributes named "ID" as being unique IDs because the HyTime architecture says an attribute named ID is an ID unless you say otherwise. Because all facilities of the HyTime architecture are optional, a processor can support just the loctype attribute and be a conforming HyTime application--support for loctype does not require or imply support for any other facilities of HyTime.] An instance of the GenericLink element type might look like this: <!DOCTYPE ... > ... <section id="chap1"> ... </section> ... <para> See <GenericLink href="chap1">Chapter 1</GenericLink> ... To deliver this document as an XML document using XPointers, you would transform the declaration as follows: <!-- XML version of previous declarations --> <!-- Declare use of HyTime architecture --> <?IS10744:arch name="HyTime" public-id="ISO/IEC 10744:1997//NOTATION Hypermedia/Time-based Structuring Language (HyTime)//EN" > <!NOTATION XPointer PUBLIC "+//IDN w3.org//NOTATION eXtended Pointer//EN" > <!ATTLIST GenericLink href CDATA #REQUIRED linktype NAME "crossref" loctype CDATA #FIXED "href QUERYLOC XPointer" HyTime NAME #FIXED "hybrid" > The QUERYLOC keyword indicates that the addressing method is some form of "query", that is, something not defined by SGML or HyTime. The QUERYLOC keyword must be followed by the name of the notation that governs the interpretation of the query value. In this case, I've declared a notation for XPointers (I made up the public ID as one has not yet been defined by W3C for XPointers as far as I know). Note that the base declaration of the href attribute has not changed, nor has the link type or the HyTime architectural mapping. We've only changed the declaration of how its value should be interpreted. The generated XML instance changes by transforming the ID reference into the equivalent XPointer specification: <?XML version="1.0" ?> <!DOCTYPE ...> ... <section id="chap1"> ... </section> ... <para> See <GenericLink href="#id(chap1)">Chapter 1</GenericLink> ... Finally, note that the *semantic* of the reference is still defined by the processing application. The fact that an attribute is referential does not, in and of itself, make the element a hyperlink. Thus, the loctype attribute serves to declare that a given attribute is, in fact, referential and how to resolve the reference (interpret its value) but does not say *why* it's referential. For that you would need to appeal to some other mechanism, such as XLink: <!-- XML version of previous declarations, now with XLink --> <!-- Declare use of HyTime architecture --> <?IS10744:arch name="HyTime" public-id="ISO/IEC 10744:1997//NOTATION Hypermedia/Time-based Structuring Language (HyTime)//EN" > <!NOTATION XPointer PUBLIC "+//IDN w3.org//NOTATION eXtended Pointer//EN" > <!ATTLIST GenericLink href CDATA #REQUIRED linktype NAME "crossref" loctype CDATA #FIXED "href QUERYLOC XPointer" xml:link NAME #FIXED "simple" HyTime NAME #FIXED "hybrid" > If you understand the rules imposed by the XLink architecture, then you know that not only is href referential, but that its purpose is to address the remote resource of a hyperlink. You didn't know that second part before. Notice that I've now combined the use of two independent architectures in one element. Processors that only understand XLink will ignore the loctype, linktype, and HyTime attributes. Processors that only understand HyTime will ignore the xml:link attribute and processors that understand both will have redundant information about what the href attribute is all about (because it is implicitly a reference interpreted as an XPointer by XLink's rules an explicitly so as declared by the loctype attribute). Cheers, Eliot -- <Address HyTime=bibloc> W. Eliot Kimber, Senior Consulting SGML Engineer Highland Consulting, a division of ISOGEN International Corp. 2200 N. Lamar St., Suite 230, Dallas, TX 95202. 214.953.0004 www.isogen.com </Address> xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto: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
|