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 20010618


Regrets: David
Present: Normand, Lauren, Tony, Paul, Norm, John

Minutes from last week accepted.

Rob's five questions:
http://lists.oasis-open.org/archives/entity-resolution/200106/msg00022.html

1) motivation for rewrite catalog entry: editorial

2) one section talks about normalization but it isn't completely defined - editorial

3) also editorial

4) an avalanche of email as whether un-absolutized URIs may be passed to the 
catalog. This may be irrelevant to us, since the catalog processor can only deal 
with what it's given.

Spec should say something like "it compares the URI that it is passed; ideally 
what was in the document but if the underlying processor absolutizes this URI, the 
catalog processor will compare that absolutized URI."

One possible erratum to the XML 1.0 spec; Norm may propose 4.2.2. change to allow 
the system identifier to be allowed to generate an alternate URI reference, and 
not just the public identifier. We are sure that excluding such generation of an 
alternate URI reference from a system identifier was not intended by the XML spec, 
even if it can be read that way.

5) small inconsistency in the spec. All entry types except rewrite return the URI 
reference, but rewrite returns a string. Is this correct? The RHS is not a URI 
reference string.

A rewrite rule is essentially shorthand for a collection of maps of entries; one 
use case is to publish a directory from one place to another, where everything is 
relative. What is the interpretation of the strings? In the system entries, 
relative on the RHS is relative to the baseURI of the catalog. So the rewrite 
should work the same. If you know what you're doing in the catalog, the RHS could 
be absolute. The point to relative URIs is to make things portable. Catalog 
resolution is done at document interpretation time. You may wish to move the 
catalog with everything else. Can work it out so that the baseURI of the catalog 
is in the right place to get the relative URIs. Paul can live with having the 
rewrite RHS be absolutized wrt the base URI of the catalog, to keep it consistent 
with other keywords.

Question: if the result of applying a rewrite rule to a system ID or a URI is not 
absolute, does the catalog processor return the relative URI, or does it 
absolutize the entry wrt to the base URI of the catalog entry?
What happens if the catalog processor can't make the entry absolute, because it 
won't be a valid URI? The result is implementation-defined.

The results of the vote were for absolutized URI.

Nobody is aware of any other issues in the draft.

Norm will prepare what we think is the final draft by the 27th. We will meet again 
July 9th.

What do we do with John Cowan's code? If it's a committee work product, it may not 
be changed; what do we do with the code? OASIS will need to solve this problem. 
Norm will update the web page to point to those.

Lauren will raise the issue of what to do with these with OASIS.

Lauren

-- 
-----------

Lauren Wood, Director of Product Technology, SoftQuad Software
Chair, XML 2001 - Call for presentations now open at www.xmlconference.org



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


Powered by eList eXpress LLC