xml-dev - Re: Response to Simon St.L. on Entities v. XLL

[len bullard <cbullard@hiwaay.net>]

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@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)