Re: 4.1 Address types

At 12:33 PM -0800 3/4/97, Tim Bray wrote:
>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).

I don't like locator types. We should define a fixed list of types, and
leave it there -- interoperability and simplicity are not served by making
obvious extension mechanisms that people should not use.

I don't mind the single locator that much, but I'm not sure why it's an
issue... Are locators going to appear in the content of elements? I think
that's a bad idea because it violates many people's expectations that "tag
stripping" makes sense. It doesn't always, but putting link addresses in
content means that authors can no longer choose to use a tagging style in
which tag-stripping does make sense. This seems a problem to me.

>
>4.1.b If so, what should the attribute be called?

nonexistent

>4.1.c If not, should we use a different attribute for each type of locator?
>Note that this means we could in principle have multiple addresses per
>locator element although only one of each HRTYPE.

Seems too complicated. Locator syntax should differentiate locator type,
via URL syntax.

>4.1.d If using different attributes for locator languages, can we have
>multiple locators packed into locator attribute values?

This is a good reason for a single locator attribute -- although I strongly
believe that we should _not_ have multiple locatore languages: if TEI is
not enough, then XML should extend it, not add others in.

>4.1.e Should we discard this scheme and adopt something wholly different
>for selecting among locator languages?

URL syntax, and self-indentifying fragment IDs. Possibly some LOCSRC-like
way to spcify a base URL, or starting entity (for XML syntax-based location)

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

Yes, I think. We could require a declaration to tell the difference: CDATA
link attributes would be URLs, and IDREF attributes would be IDREFs with
the same properties as today.

Worst case, we make IDREFS look like "#sdfds" and change the SGML concrete
syntax slightly.

replacing spaces with commas in the TEI locators makes soemthing that packs
nicely, as Steve has pointed out to me before now...

   -- David

_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________

Received on Wednesday, 5 March 1997 15:36:54 UTC