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 20010514


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

Minutes from the last meeting accepted.

Version numbers for the namespaces: no objections to dispensing with version 
numbers for namespaces for this catalog specification.

spaces in URNs: "+" is more readable, but "%20" is more standard in URLs so 
there may be compatibility issues with using "+". However, urn:publicid is a 
new thing anyway, and this is a way to turn URN publicids into FPIs and back 
again. Thus new code has to be written anyway to do this work. So the 
apparent legacy issue is not really there.

Is using "+" a trend? Many URN namespaces don't allow spaces so they avoid 
this problem. The one exception we know of has "%20". Since this internet 
draft is not an official work product of this TC, any resolution we come to 
is not binding on the drafters anyway, and their decision may be appealed 
through the standard IETF mechanisms.

+: Tony, Norm, Paul
%20: David
abstain: Normand, Lauren

What do we do with urn:publicid when it is handed to the processor as a 
system ID? We could unwrap it and treat it as a public ID if it asserts to 
be a publicid. If there are syntax problems, then it won't have the same 
semantic behavior. There may be doctype declarations with 2 public ids and 
no system id. What we may be trying to do is get public ids into the Web 
architecture, which means treating them as public IDs no matter what. If the 
urn:publicid doesn't match when unwrapped, maybe it has a fallback behavior 
as an opaque string. We shouldn't differentiate between registered and 
unregistered public ids. The translation between the urn:publicid and public 
ids is purely syntactic, so requires no knowledge of public id semantics.

We could describe a consistent way to deal with the unlikely situation of 
having a publicid and a urn:publicid. Mostly people will use urn:public when 
only system ids are allowed, but people want a public id. Maybe it is 
incorrect to unwrap a urn:publicid when it occurs after a PUBLIC identifier. 
Thus it would only be unwrapped when it's in a system identifier.

What do you delegate on? If you argue that it's a public id, then you don't 
have a system id to delegate on.

If a resolver is passed a urn:publicid as the value of a system id or a URI, 
then we take the unwrapped value and assume that to be the value of the 
public id. If there is already a public identifier on say, the doctype 
declaration, then they should have the same value. If, however, they don't, 
then there are five possibilities:
1) error
2) abandon the public in favour of the system
3) abandon the system in favour of the public
4) use them both, with public first
5) use them both, with system first
6) keep both and walk through the catalog and alternate which gets 
preference based on the prefer setting (probably tricky to implement)

The easiest thing to do is to call it an error (no objections). Then we 
could have a fallback of the resolver returning no match; the user may be 
unhappy with a false validation. We're really saying you can't have two 
public ids for a document. The definition of an error here means that the 
resolver may recover from this error or not, as it chooses. If it does 
choose to recover, the method of recovery must be to choose the public id, 
because there is less probability of error, since the system contains the 
encoded version of the public id. No objections to this.

25) Should we add an oasis:publicLocation attribute to handle what XML
Schemas elected not to support?
This is not necessary because people can use urn:public in their system IDs; 
the schemaloc is a list and schema processors can choose whichever they wish 
to anyway.

What is the status of the urn:publicid draft? It has been submitted to the 
IETF URN WG. It can then be moved on to the steering group for publication 
as an informational RFC. It could be an RFC in three months.

Next meeting: Wednesday 10 am Pacific to finish the issues. Lauren to kick 
off the catalog naming email today.

Lauren



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


Powered by eList eXpress LLC