Lists Home |
Date Index |
- From: len bullard <email@example.com>
- To: Peter Murray-Rust <firstname.lastname@example.org>
- Date: Mon, 01 Dec 1997 18:15:17 -0600
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,
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
is to ensure persistence. Is an FPI needed for a typing object (what is
> Using a SYSTEM Id is subject to the problem of permanence and uniqueness of
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
> >* 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.
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)