[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