- From: Terry Allen <tallen@sonic.net>
- Date: Tue, 4 Mar 1997 16:46:27 -0800
- To: tbray@textuality.com, w3c-sgml-wg@w3.org
| 4.1.a Should we have a single attribute used for storing all locators, | with another attribute expressing its type, as with the initial draft's | HREF/HRTYPE? Note that this has the side-effect that a locator element | can contain only one locator (which of course, could be a tokenized list). Could those who know what the XML sdecl really says comment on whether a list of URLs and URNs could be tokenized with white stuff in XML? Can it contain %, :, /, and that stuff? | 4.1.c If not, should we use a different attribute for each type of locator? If "type" means what HRTYPE used to mean ("identifies the interpretation fo the HREF"), the author should be able to do this. But I'm wondering about how I can do the following in the draft of 31 Jan 97: <tire-manufacturer car="carttp:mycar" spare="http://www.bridgestone.com/" lf="http://www.michelin.com" rf="http://www.michelin.com" rr="http://www.michelin.com" lr="retread">click to check on inflation specs</tire-manufacturer> if I can have only one HREF and one HRTYPE on each element. Apparently I would have to write: <tire-manufacturer xml-link="xml-mlink"> <whichcar xml-link="xml-pointer" href="carttp:mycar" hrtype="123"> <spare xml-link="xml-pointer" href="http://www.bridgestone.com/" hrtype="234"> <lf xml-link="xml-pointer" href="http://www.michelin.com" hrtype="345"> <rf xml-link="xml-pointer" href="http://www.michelin.com" hrtype="456"> <rr xml-link="xml-pointer" href="http://www.michelin.com" hrtype="567"> <lr xml-link="xml-pointer" href="retread" hrtype="678">click to check on inflation specs </tire-manufacturer> which avoids using either href or hrtype more than once in any given start-tag. Or, if I can map the attributes of arbitrary GIs to their XML semantics outside the start-tag, I must have at least: <tire-manufacturer> <whichcar href="carttp:mycar" hrtype="123"> <spare href="http://www.bridgestone.com/" hrtype="234"> <lf href="http://www.michelin.com" hrtype="345"> <rf href="http://www.michelin.com" hrtype="456"> <rr href="http://www.michelin.com" hrtype="567"> <lr href="retread" hrtype="678">click to check on inflation specs </tire-manufacturer> that is, I can't conflate in one attribute role and addressing. Seems to me that with any of the associative mechanisms proposed that should be possible (that is, I should be able to do what I showed in the first example). | 4.1.d If using different attributes for locator languages, can we have | multiple locators packed into locator attribute values? Same as 4.1.a's "tokenized list"? | 4.1.e Should we discard this scheme and adopt something wholly different | for selecting among locator languages? Provide a hook in the as-yet-completely-undefined general architecture for this information, specifying one small language, and specify the well known keyword for it. | 4.1.f Should we abandon the idea of different address types and assert that | everything is a URL? Can we do this and retain support for good old | IDREF(S) addressing? Does XML-LINK need to subsume IDREF(S)? This | would require packing complex addresses (e.g. TEI locators) into URLs. You won't be able to do very much with that which is not a URL. So far as I can see, IDs can be treated as fragment identifiers postpended to (possibly relative) URLs. It's URLs that subsume IDs. It would be possible to construct TEI locator encodings, or even Hytime locator encodings, using URLs and fragment identifiers. But there are many ways to do it. Turn the question around, and ask, "is there any reason for the SGML ERB to construct a way of encoding complex addresses if URLs will do instead?". I think further investigation will show you want to use queries, not fragment IDs (answering some other question in this train). Regards, Terry Allen Electronic Publishing Consultant tallen[at]sonic.net specializing in Web publishing, SGML, and the DocBook DTD http://www.sonic.net/~tallen/ A Davenport Group Sponsor: http://www.ora.com/davenport/index.html
Received on Tuesday, 4 March 1997 19:46:18 UTC