Re: Response to Simon St.L. on Entities v. XLL
Peter Murray-Rust wrote: > > At 21:29 30/11/97 +1100, Rick Jelliffe wrote: > > > > > >* The SGML entity mechanism is based on having type information as part > >of the declaration of the entity, not in the entity reference and not in the > >entity itself. > > I am very interested in automatic Typing of information components and > think that this will be a very active area for the XML community. It is an active area for any community that must associate semantics in interoperable frameworks. In SGML, this is the level of interoperability that typically is not specified. The issue of interoperable semantics is system implementation. That is obscure in XML to me. > XML(SGML) entities (NOTATION) have traditionally used PUBLIC and FPIs > (Formal Public Identifier) for adding type information. This works if there > is a registry of FPIs for this purpose. Without it is not much use. Any framework that depends on registration to associate semantics with markup based on FPI, URN, MS registry, etc. has the requirement for maintenance. No discussion I've read of this subject assumes otherwise. The discussion typically breakdown in the discussion of the mechanism. In all the variants of SGML systems (eg, XML, HyTime, DSSSL, etc) different mechanisms are proposed and all have camps of adherents. All of the systems have been shown to work, so, in essence, picking one to implement has become an issue of economy and polity. > My impression - and I'm happy to be corrected - is that there are few useful > FPIs for Typing objects. Hmm, please clarify? The usefulness of the FPI concept (any registry, i guess) is to ensure persistence. Is an FPI needed for a typing object (what is a typing object)? > Using a SYSTEM Id is subject to the problem of permanence and uniqueness of > URLs. Is there a form of unique identifier that does not? Registry systems are a level of indirection under a regime of authority (e.g, who gets to declare, modify, delete, copy(distribute) unique identifiers). > >* The XLL mechanism (well, I should say the MIME mechanism really) is > >based on the entity being self-identifying as to type (aided by > >any additional attributes you like on the linking element). > > Unfortunately, not all targets of XLL HREFs will be self-identifying. This > is true of local files and not-very-smart-servers. Right. A question that arises is one of where maintenance should occur. This is a systemic requirement of scope. What is the scope of the system which uses the files? Local is not a satisfying answer in a linktoAnythingAnywhere system. If not LTAA, eg, a local Intranet is creating XML, XML DTDs, other to be determined schema mechanisms, why should they be restricted to the use of MIME typing? If not, where should they maintain a registry that is both local to the Intranet and useable by a larger Intranet. SGML practice reveals the need to maintain communities of DTDs that specify different document types being created and destroyed within the same overall framework of *processes* (eg, a business). What do you think is the best way for both the data creators, maintainers, in the process/production environment to do this? > It is therefore useful > for the author to be able to add MIME types to the target. > As yet, MIME is not part of the XLL mechanism. I wish it was, and keep > squeaking for it. If it isn't I suggest we use XDEV:MIME as a FUA > 'frequently used attribute' in XML-LINKs. MIME. Ok. The problem is that the registry type *is assumed* to specify mechanism and authority of the registrar. If the mechanism is adequate(depends on requirements; anyone have functional requirements for XML?) then the only issue is the polity. IOW, should an XLL link be constrained to one mechanism? Requirements? The polity is an issue for XML of its origins in the W3C. For SGML, that is ISO. Divergence on the decision of formal public registries could have a chilling effect on the common community. Len Bullard xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format