Re: 4.1 Address types

| 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:

     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
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:

     <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
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).

  Terry Allen    Electronic Publishing Consultant    tallen[at]sonic.net
       specializing in Web publishing, SGML, and the DocBook DTD 
  A Davenport Group Sponsor:  http://www.ora.com/davenport/index.html