Re: 4.1 Address types
At 12:33 4/3/97 -0800, 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).
Yes (though you don't need HRTYPE if you follow the suggestion below!)
>4.1.b If so, what should the attribute be called?
>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.
>4.1.d If using different attributes for locator languages, can we have
>multiple locators packed into locator attribute values?
>4.1.e Should we discard this scheme and adopt something wholly different
>for selecting among locator languages?
If by "this scheme" you mean the idea of having differently named locator
elements for different HRTYPES then you should most definitely discard it.
Why not adopt the FSI approach to identifying locator schemes, viz:
You get nicely delimited entries/tokens
You get qualifying properties like FSIBase
You get multiple types of locators without needing an HRTYPE attribute
You can mix and match locator types
You have a defined order in which to access locations
All this using standarized SGML components with nothing invented
specifically for XML. What's more you have a fully extensible scheme.
>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.
NO, NO and NO.
Martin Bryan, The SGML Centre, Churchdown, Glos. GL3 2PU, UK
Phone/Fax: +44 1452 714029 WWW home page: http://www.sgml.u-net.com/