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: Minutes for 2001-04-02?




Tony Coates wrote:

> 
> Are there any?

Thanks for the reminder! I forgot I hadn't sent them.

Here they are.

Present: Lauren, David, Norm, Paul, Tony

Minutes from the last meeting accepted but Norm has some questions.

Issue 2: "general agreement on this" should be struck from the minutes. Norm 
wishes to make explicit what is currently implicit, namely that XML 1.0 + 
namespaces is required.

=======================

Issue 12: Norm wishes to re-open the discussion. No objections. The argument 
is that allowing names in null namespace to be interpreted as catalog names 
will complicate processing. Paul wants it to be feasible for catalog 
processor to not need namespace support, or for catalogs to not use 
namespace prefixes. We could define default namespaces that are predeclared 
in the spec. This would work for DTDs; Norm is not convinced it makes any 
sense to not be namespace-aware if you support schemas. The DTDs and schemas 
are non-normative, so we would need the namespace declaration to be required 
in the normative part of the spec. Our examples should use the namespace as 
an attribute on the DTD. If you provide a doctype declaration for the 
catalog, then the default DTD provides the namespace declaration. If the the 
catalog is WF and supplies the default namespace declaration, that will 
work. If the catalog is WF and doesn't supply a default namespace 
declaration, then there may be implementation problems. There is no publicly 
known XML processor that allows you to assert the namespace in this last 
case. The processor would have to decide at the top what the namespace is. 
Discussion about whether the processor needs to ask the same question at 
each element, whether it's in the null namespace or the default namespace. 
Tony thinks we shouldn't allow people to add prefixes on some things and not 
others, since he thinks they should be in a consistent namespace. Should 
this be explicit, or can the null namespace also be this namespace? Norm 
disagrees as to what is harder from an implementation pov.

If we have an XML catalog and also need to process SGML, will this be 
prohibited by allowing null namespace entries into the catalog? It shouldn't.

Paul is willing to have the default namespace logically be on the catalog 
element. This implies that this is not the null namespace.

Vote: in order to be recognized as elements in an XML Catalog, the elements 
must be in the correct namespace. (This means that the null namespace is no 
longer considered valid for elements in the XML Catalog).
Agree: Tony, Norm, Paul, David, Lauren

Attribute question: unprefixed attributes are in the per-element namespace. 
An attribute with an explicit namespace prefix is in the global attribute 
partition. Norm suggests that global attributes in the catalog namespace 
aren't  recognized and are an error (effects must be ignored, but an error 
message can  be raised). Norm's concern is that we need to cover the 
ambiguous case of the  global attributes. General agreement on this point.

PI issue: the use case is adding a PI to the document to be able to have a 
per-document override of the starting catalog. Discussion as to what 
"starting" means. The user of the catalog may be the application, not the 
user of the application. So far, we've only had a way to add a catalog 
placed after the other catalogs. Tony wants this to be able to test without 
shutting the system down or affecting other users. The application works by 
using some default catalog files. Since the application will have already 
loaded the document and the doctype before getting to the PI that 
potentially changes the doctype, this can cause problems. If the DTD is a 
different DTD, what should the application do? Restart? In some areas users 
will not be allowed to change the catalog path. This PI could be ignored in 
production systems. Motion to postpone until John Cowan can attend.

Next meeting on Easter Monday: move to Tuesday 17th instead.

Lauren



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


Powered by eList eXpress LLC