[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