- From: Eve L. Maler <elm@arbortext.com>
- Date: Fri, 14 Mar 1997 15:01:21 -0500
- To: Tim Bray <tbray@textuality.com>
- Cc: W3C-SGML-WG@w3.org
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> <!ATTLIST XML-LINK ROLE CDATA #FIXED "LINK" LOCATOR CDATA #IMPLIED IDREF IDREF #IMPLIED IDREFS IDREFS #IMPLIED ENTITY ENTITY #IMPLIED ENTITIES ENTITIES #IMPLIED ... > Eve
Received on Friday, 14 March 1997 15:05:23 UTC