[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: minutes from ER TC teleconference 20010122
Roll: Lauren, Norm, Tony, David, John, Paul Minutes: accepted as amended by Paul's email. FAQ entry: Paul's suggestion of Wed Jan 10. No objections to accepting this high-level definition. Norm to add this to the web page today. Paul's email from Tue Jan 9, subject line "Re: 8 Jan 2001 Entity Resolution Draft" Issue 1: Last part of abstract reads: To address these issues, this resolution defines an entity catalog that maps an entity's external identifier and/or name to a URI. Since we don't appear to be including the ENTITY entry type (or are we?), then we should delete "and/or name". Resolution: agreed. Issue 2: Also, since we have decided that we aren't (and shouldn't) address what was Issue B of TR9401, I think it's time to delete mention of it in the abstract and intro (and then delete mention of Issue A in the intro since there is only one issue). Resolution: agreed Issue 3: In fact, the abstract and intro could probably stand to be rewritten completely in light of current events. Resolution: agreed. Issue 4: In the example, you show a namespace prefix on the <public> element. What gives? Don't tell me we have to have namespace prefixes on every element in the catalog! I thought namespaces were to be used for the extension mechanism, but I see no need for them on the elements we are defining. Resolution: we have a substantive issue of the actual namespace. Do the catalog names need to be in a namespace? Add to issues list. Issue 5: In the last entry of this example, you've got a "ur" attribute instead of "uri". Resolution: fix this. Issue 6: I note that we will need more examples (I realize the original TR9401 didn't have many). Resolution: agreed Issue 7: I realize since this catalog is an application of XML, it "makes sense" to use schemas and dtds to define its syntax rather than eBNF, but geez, that schema is quite daunting, and I'm unlikely to study it carefully enough to tell whether it's correct or not--I guess I'll just trust you. Resolution: some disagreement on whether well-written prose is the normative version, and whether a formal representation also needs to be, or can be, fully normative. A catalog also can fail gracefully; this is difficult in a schema language. Thus the schema representations will be non-normative. sub-issue 7: agreed to reference XML 1.0 normatively, namespace specification normatively, and to forbid relative URI references in namespace names. Issue 8: By the way, I note that the doctype of the schema uses a SYSTEM id that isn't very useful for anyone (except, perhaps, Norm). Is there a public id for this DTD, or will everyone have to use a catalog with a SYSTEM entry to be able to map this system id? Resolution: Norm will fix the system ids. Norm will request a public ID for the schema DTD and for the schema or schemas from the Schemas WG. The hint for a schemaloc is currently can not be a public ID. This should go into the issues list. Action on Lauren: find out who the AC rep is for OASIS. (Laura Walker) Action on Paul: write up the position that this committee may take. Issue 9: Just before "Additional requirements", note that "minimum literal" is not defined in XML. Besides, since you aren't using an EBNF to define the language, I'm not sure you need this sentence at all. Resolution: Norm will change minimum literal to refer to the correct production. Sub-issue 9: we could urge the XML Core WG to allow non-English characters in public IDs. The production is 12. Our attribute value is a string of publicid characters. Action on Paul to submit this to the XML Core WG. We could use URI escaping in public IDs, but then we could have matching problems, unless we say that %-escaping only works for characters not in the publicid character set. There may be an issue with current public ids that use % (not that we know of any). Add to the issues list: should we have a convention for non-publicid characters in catalogs? Issue 10: And Additional requirement "a." about lengths of attributes can be deleted as being irrelevant for XML. Resolution: agreed Issue 11: Add. req. "c." should be reworded or deleted--I'm not sure which--since XML Base normatively refers to RFC 2396 which defines base URI, so we don't need to say what we say here. We should probably just say something like "conformance to this XML Catalogs spec requires conformant support of XML Base" and add that all values of the "uri" and "catalog" attributes must be treated as URI references in this respect. Resolution: agreed Issue 12: And I'm not sure what add. req. "b." adds anymore, so maybe we can get rid of this whole section and replace it with the brief discussion of XML Base. Norm wanted to point out that any URI scheme could be used, even if not everyone has tools for every URI scheme. Is it reasonable to have nextCatalog use a mailto? We don't say anything about what happens if you request something and can't get it - this needs to be added to the issues list. Generalize to the notion of unretrievable resources and drop "b." - agreed. Issue 13: I'd also delete item 6 in the following list, since this would be covered by the earlier XML Base discussion. Resolution: agreed. XML Base must be a normative reference - agreed. Issue 14: In light of current events and some changed terminology, the following needs work: Generally, when a system identifier is specified in an external entity declaration, it can be trusted to be a valid URI. However, in some circumstances (such as when the document was generated on another system, when the document was generated in another location on the same system, or when some files referenced by system identifiers have had their locations changed since the document was generated), the specified system identifiers may not be valid. For this or other reasons, preferring the public identifier over the system identifier may be the preferred way of accessing the entity. Resolution: the editor will reword, using as much of Paul's suggestion as desired. Issue 15: Then later, the text that currently reads: A public or delegate entry encountered when override is "yes" (corresponding to the mode where public identifiers are preferred) will be considered for possible matching whether or not the external identifier has an explicit system identifier. A public or delegate entry encountered when override is "no" (corresponding to the mode where system identifiers are preferred) will be ignored during lookups for which the external identifier has an explicit system identifier. Resolution: put into issues document. Issue 16: Let's get rid of the section on hyphens or colons in the ISO owner identifier. Resolution: agreed. Add issue about default for override. Since Lauren can't make the next meeting, Norm was nominated and seconded as chair. Lauren
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC