minutes from ER teleconference 20010305

[Lauren Wood <lauren@softquad.com>]

Present: Tony, Normand, Lauren, Norm, Paul, John, David (late)

Minutes from Feb 19th: no changes requested.

No response yet from the Schemas WG. 

Normand posted some issues: quick discussion to see how they go.

a) there are dual XML/SGML processors - sometimes people publish SGML and
XML from the same source. Should there be a variation of the catalog for
SGML? There is the XML format with SGML catalog semantics, and also there is
the question of getting the old SGML catalog syntax. 

The new catalog has the same semantics where keywords are the same. Perhaps
nextCatalog can point to a 9401 catalog. The processor may need to know
whether to expect a 9401 catalog. Would it be sufficient to convert from
9401 catalogs to XML catalogs? How does one use an XML catalog with SGML?
Perhaps we should have another variation on nextCatalog that points to an
SGML catalog; a 9401 catalog or an XML-syntax catalog? 

Converting a 9401 catalog to XML catalogs means adding things like ENTITY;
it's probably easier to reference a 9401 catalog but John is unhappy with
that. Some people are interested in adding the SGML support. We have a way
to add SGML features to an XML catalog. We agree that 9401 support is not
mandatory for an XML catalog processor. 

We can say that nextCatalog and delegate can only point to XML catalogs.
Potentially recommend an addition to 9401 catalogs to cope with the
interoperability issue. Add this to the issues list.

b) tools to convert: shouldn't be too hard to convert. If someone does it,
we could reference it non-normatively. John will write such a converter.

c) should we allow an instance to point at a catalog to override processing
defaults? If this is allowed in a PI, then the PI could be overridden. Maybe
the processor should say which set of catalogs should be used. Does the
catalog primarily belong to the author, or the recipient? Often they're used
by the recipient to overcome deficiencies in what the author set. The author
can also use them, by using the catalog with a set of entities. Packaging
requires a catalog. We aren't doing packaging. Could an instance document
recommend a starting catalog? We really couldn't do more than a hint of
where a useful catalog might be. John will write up a trial.

Namespace entry: do we want this, or arbitrary URI? Norm and John like the
arbitrary URI idea; it helps with the delegate issue. Everyone supports this
proposal, even Paul after lots of discussion. A few issues now fall off,
such as the question about a stylesheet entry. Should we have a purpose
attribute? Maybe just reserve all attributes that aren't namespace
qualified. All elements that belong to our namespace are reserved, and all
non namespace-qualified elements. We need a version attribute on the catalog
somewhere so version 1 processors know what they need to understand and what
they can ignore. Issue: should version 1 processors ignore what they don't
understand?

Identifying public IDs within a schema: should we have an attribute outside
the schema namespace to add this information? The catalog processor would
resolve the public ID to a system ID and pass that to the schema processor.
Norm is updating the URN proposal. This has the advantage that the XSI
schema hint works both ways. The URN resolver is a front end to a catalog
processor. This question has been added to the issues list. 

Lauren