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: minutes from ER TC 20010417


Present: Paul, Lauren, Norm, Normand, Dave, John
regrets: Tony

Minutes from last time accepted.

Prefixed attributes: issue has been clarified; no changes required.

PI issue: adding an override of the catalog is tricky. An individual 
user can use a local catalog. Putting it in the document is late; it 
would need to go before the doctype to give the processor a 
chance to find it before it loads the DTD and some processors start 
loading anyway. This could be a hint from the author. Is it needed 
for document exchange? What happens if someone wants to use a 
public catalog? A sophisticated user will use a local catalog that 
can delegate to a public catalog when necessary. Making this work 
in practice is going to be tricky since implementations tend to set 
up catalog stuff before starting parsing. Being able to refer to global 
catalogs without needing local catalogs seems to be the most 
compelling use case so far for this idea. 

If we were to do this (not yet decided), John proposed a PI. We 
could associate a URN or URL with a notation that will 
unambiguously send this to OASIS. In practice, we could probably 
just use something like an OASIS- target. General agreement on 
using this target name.

John would also like to restrict this PI to appearing in the prolog, 
before the doctype declaration or the document element. It must 
appear before anything that can be referenced from the catalog, so 
before stylesheet PIs as well as the doctype declaration or the 
document element.

Is this an override catalog, or an add-on catalog? In the public 
catalog use case, it doesn't matter. Norm is more comfortable 
putting it at the end so the implementation doesn't have to restart 
the catalog machinery. Allow multiple catalogs; they just all get 
added on at the end.

Is this PI subject to catalog resolution? The same question comes 
up with the nextCatalog keyword. Since in 9401, it was an soi, 
then it shouldn't be subject to catalog resolution, although it will be 
subject to base resolution. 

The implementation starts by searching a list of implementation-
defined catalogs, and then the catalogs listed in the PIs. The PI 
attaches the catalog entry files to the end of the catalog entry list. 

The author can mention some number of public catalog files. E.g., 
the DTD mentions ISO entity files on the ISO site, the CALS table 
model on the OASIS site, and some stuff from W3C.

Postpone the vote on whether we actually want this until next 
meeting. Current thinking: it seems reasonably implementable.

Schemas and public IDs: with persistent URIs, we can mimic most 
of the effects of public IDs, so we have decided not to push this 
any further with the schemas WG.

Norm: we have looked at several drafts of the ER; we're nearing a 
point where maybe we should ask the world to look at this closer. 
Norm proposes that we vote whether to accept the next draft as a 
public committee draft, send email to xml-dev etc, and do a press 
release. Would this be an OASIS press release? Probably. 
Discuss the PR idea further next time.

Meeting recessed.



Lauren


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


Powered by eList eXpress LLC