Re: Recent ERB Work on URL addressing
At 08:48 AM 3/14/97 -0800, Tim Bray wrote:
>This report is on the last couple of ERB meetings, on March 8 and 12th.
>The majority of the time was spent on the issues (the discussion items
>numbered 4.*). One issue is central: can we afford to assert that all
>XML locators are URLs? The advantages are huge:
> - no need for separate locator-language machinery
> - web conformance. On the WWW, locators are URLS, and that's that
> - existing understanding and machinery
>There is one substantial downside: pure XML IDREFs cannot in this
>framework be XML Links; a URL consisting only of a Name is interpreted
>in URL-talk as a relative URL - you'd have to put a leading '#' in order
>to get IDREF behavior. You could rely on the declaration - if its
>declared IDREF, then you know - but this probably requires DTD processing
>in order to recognize links, and adds complexity; neither are good.
Explicit link recognition needs "DTD processing" anyway, whether the
ATTLIST machinery is in the external or the internal subset. (The latter
is more trivial to retrieve, but no easier to process.)
Given than IDREF[S] and ENTITY[IES] are usually only interesting in the
cases where the relevant ATTLIST is read, I'd prefer that we sanction these
as links in XML by allowing them to have the XML-LINK="LINK" on them and to
dictate the "template" (that is, arch form) requirements for these attributes.
If you supply just an IDREF[S] value, then it's a fragment identifier
relative to the current document. If you supply an ENTITY[IES] value, then
it's just an indirect way of pointing to a URL (which is what entities have
to resolve to anyway, right?).
The tricky part would be doing the entity-plus-ID in separate attribute
values, which is a really common thing to want to do. If you supply an
IDREF[S] that's intended as a fragment identifier relative to the entity,
you'll get a validation error if the entity isn't the current document
(though you may not care about validation errors). Perhaps, when
ENTITY[IES] is supplied, the regular locator attribute value can be
interpreted as the fragment identifier relative to the entity, and too bad
if you don't combine them properly.
FWIW, here's a concrete proposal, with a few comments/questions:
o LOCATOR here is the all-powerful locator attribute. The locators
that have special declared values are named after the declared values.
o Does "ANY" allow the element to be declared "EMPTY"? I think we should
allow this! How can we get the template/AF to indicate it?
o What I mean is to allow *either* IDREF or IDREFS, and *either* ENTITY
or ENTITIES. How do you do this in a template/AF?
o If the element and attribute names become canonical, then perhaps DTD
processing *isn't* needed in the cases where the name matches up with
the declared value.
<!ELEMENT XML-LINK ANY>
ROLE CDATA #FIXED "LINK"
LOCATOR CDATA #IMPLIED
IDREF IDREF #IMPLIED
IDREFS IDREFS #IMPLIED
ENTITY ENTITY #IMPLIED
ENTITIES ENTITIES #IMPLIED