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 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

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

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

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
  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

Resolution: agreed.

Add issue about default for override.

Since Lauren can't make the next meeting, Norm was nominated and
seconded as chair.


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

Powered by eList eXpress LLC