[Prev][Next][Index][Thread]

Re: XML catalog draft



Despite the fact that I was on the committee that came up with the
socat-subset, I would support this decision. I have always been on
the fence about whether we should do a default resolution mechanism
or not. I would love to see SOCATs widely implemented, but don't 
know if the extra burden may put some potential XML implementor
over the edge into: "Maybe I'll just do HTML 4.0 instead." It's a
gamble I was never thrilled about, though the potential win is
large.

All I've ever asked for (begged, really), is to keep the PUBLIC 
syntax in so that we can continue to use it by pre-arranged 
convention and perhaps standardize a default resolution mechanism
when the XML community is a little more mature. Your proposal
preserves this, and I am about as happy with it as I would be with
a simple default resolution mechanism (though not as happy as I would
be if we could both specify a default resolution mechanism and 
*guarantee* that it would be implemented - but that's not an 
option!).

> - make a decision as to what should be done when both PUBLIC and SYSTEM
>    are there

Whichever goes first, the failure of one should not be a reportable
error, only the failure of both should be, in my opinion.

>  - investigate the problem of what seems like the unnecessary
>    restrictions on MINIMUM LITERAL; I don't think it's legitimate to
>    say that a PUBLIC identifier can't be a URN, which this would do.

Aren't URNs more transport-resilient than that? They can probably 
be URN-encoded to use only minimum literal characters, can't they?

> I'm not sure what the right thing to do is with the current
> catalog proposal.  It seems to represent the best thinking of the people
> who know on how to get good mileage out of Socats; it would be a 
> pity to lose that.  But at the time it just doesn't seem like a good call 
> to wire this into XML.

This proposal is different than TR 9401. For one thing it could be 
tuned for XML a little more (ie URLs instead of system literals), and 
for another it has delegate which TR 9401 does not (as I recall). 
We could consider publishing it as a W3C Technical Report.

 Paul Prescod


References: