OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

entity-resolution message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: Catalog Requirements


/ Paul Grosso <pgrosso@arbortext.com> was heard to say:
| At 14:03 2000 11 16 -0800, Terry Allen wrote:
| >Paul wrote:
| >| But URI is orthogonal to PUBLIC, SYSTEM, etc., and it going to be 
| >| a mess.  I don't want to go there.  
| >
| >Okay.  We do need URI>URI mapping, though.  Let's imagine it
| >happens through (some piece of some processor) consulting another 
| >map.  (If anyone wants references to previous URN-WG work on
| >such maps, let me know.)
| 
| Careful that you don't mix layers.  Without getting into the
| discussion of whether URI>URI mapping is good or bad, it is
| not part of XML entity management and does not belong mixed
| in with an entity management catalog.

(I can play both sides of this issue, just watch me :-)

While it would be easy and convenient to constrain our work only to
the narrow cases that arise from entity management in XML (which in
turn are a subset of the cases that arise in SGML), I'm not sure we're
going to do our community a lot of good if we take that narrow a view.

It seems likely that not-to-distant XML systems will have no remains
of DTD syntax at all. We need to provide a little more support for
those systems.

Just as traditional entity management has classes of identifiers (what
Paul calls functional classes, I think), XML systems have classes of
identifiers. The classes that spring to mind for XML are

  SYSTEM
  PUBLIC
  NAMESPACE
  SCHEMALOC
  STYLESHEET
  INCLUDE

If we provide URI/URI mappings for these classes, I think we'll be
near the 80/20 point. (INCLUDE, btw, is for things like <xsl:include>,
<xsd:include>, and <xml:include>. But if we decided that those were
SYSTEM identifiers, I could live with that, too.)

| >What piece of what processor would we like it to be, and should
| >the mapping be done before or after the xmlcat is consulted,
| >or both?  and should the two items (URI map and xmlcat) be
| >consulted by the XML processor or by some new, specialized
| >processor that feeds its results into the XML processor?
| >
| >or something else?

For the functional classes that we identify, I think the xmlcat
processor should be consulted. For application-specific purposes, I
think a specialized xmlcat processor should be used, one that
recognizes your extensions to the xmlcat.

Terry, you're going to hate this :-), but I suggest that
application-specific mappings should occur in the xmlcat in a
different namespace.

                                        Be seeing you,
                                          norm

-- 
Norman.Walsh@East.Sun.COM | He who seeks happiness for himself by
XML Technology Center     | making others unhappy is bound in the
Sun Microsystems, Inc.    | chains of hate and from those he cannot be
                          | free.--The Dhammapada


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC