Re: suggest validator prefer URI to FPI

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dan Connolly <connolly@w3.org> wrote:

>>>I suggest adding entries that key on the URI before those entries,
>>To what purpose?
>
>I answered that elsewhere in my message, though evidently not in a way
>that persuaded you.

I'm sorry, I saw nothing that seemed relevant. Perhaps you could repeat the
relevant part?

(
  You are aware that adding SYSTEM entries to the catalog will not make
  the Validator prefer «URIs» to FPIs, right?  All it would do is make it
  use the locally cached version of the file instead of going to the
  network for every request.
)

>>>The validator seems to recognize the given FPI and ignore the URI:
>>The Markup Validator will prefer the PUBLIC Identifier to any SYSTEM
>>Identifier, yes.
>
>I'm suggesting that's a bug.

I disagree. Can you point me at some supporting reference for that position?
Is this based solely on the preference for URIs in the WebArch document?

( cf. above; this is affected by «OVERRIDE [YES|NO]» in the catalog )


>The validator is an important outreach mechanism;

I'm glad we agree. :-)


>it's one way that a lot of people get exposed to principles of Web
>Architecture in a tangible way.

Hmmm. No, not really. Demonstrating the «principles of Web Architecture» is
not a design goal of the Markup Validator, at least not a key goal.

Facilitating the use of Valid markup, and raising awareness of web standards,
is quite sufficient to chew on for a while. To incorporate the lofty goal of
showcasing «Web Architecture» would be biting over far more than we're able to
chew, and, I would argue, would dilute the current strengths of the service.

Granted you weren't (apparently) suggesting quite that, but...


>Hence the arguments in the Web Architecture document are not irrelevant;
>it's important that the markup validation service exhibit the principles of
>Web Architecture.

Certainly. But not first-and-formost and not to the exclusion of all else. In
particular I find your argument — at least, as far as I understand it — to be
more politically or socially motivated than technical, and hence is better
suited to be accomodated where practical rather than adopted ex cathedra.


>I'm interested to know if others find the arguments in
>http://www.w3.org/TR/webarch/#uri-benefits
>persuasive or not; i.e. whether they agree with me that the markup
>validation service should prefer URIs to FPIs.




>>>SYSTEM "spec.dtd" "http://www.w3.org/XML/1998/06/xmlspec-v20.dtd"
>>No, probably not.
>
>OK; I hope it'll get removed soon (provided others concur with us). I'm
>happy to remove it if you prefer.

I can't see that removing that entry will have any (significant) adverse
effects, so if you feel you have a handle on it then by all means go right
ahead.  I'd need to look into this to see what the current state of the issue
is first; I haven't looked at it in quite some time.


>The early versions of the XML Recommendation are not valid XML
>documents; the markup validation service should not say that they are;
>it should not mask bugs.

Agreed. But note that some times this is a very fine line to walk.


>>Hmmm. Is this the "Network Effect" you were thinking of?
>
>In a way, yes: the same link checking techniques that work for <a
>href="...">...</a> can and should be applied to references from
>documents to external subsets; the bug in the early XML recommendations
>could have been caught earlier. But people were using on another system
>of identification, FPIs, and so did not benefit from the existing URI
>infrastructure; they didn't get the network effect benefits.

Actually, the problem here was that they were *not* using the «existing […]
infrastructure» of FPIs — which predate «URIs» quite significantly — but were
for some reason using SYSTEM identifiers *and* were not bothering to check
their work with any of the existing tools. Validation — be it with PUBLIC or
SYSTEM references — would have cought this problem (hence the workaround in
our catalog file).


>>That noisome negative part of the whole "network effect" hype that so
>>many dotcoms failed to take into account?
>
>I don't understand what you mean by that.

You made the connection that use of URIs as SYSTEM identifiers in preference
to PUBLIC identifiers is, ipso facto, desireable due to the «network effects»
of URIs. This conveniently leaves out the fact that the economic theory of
«Network Effects» does not imply that all the «effects» will be positive; and
neither does the term's shoehorning onto technology issues.

- -- 
We've gotten to the point where a human-readable, human-editable text format
for structured data has become a complex nightmare where somebody can safely
say  "As many threads on xml-dev have shown, text-based processing of XML is
hazardous at best"  and be perfectly valid in saying it.     -- Tom Bradford

-----BEGIN PGP SIGNATURE-----
Version: PGP SDK 3.0.3

iQA/AwUBQRFX4qPyPrIkdfXsEQKIXACcD8dG0tuhC6zbWAxHGA1mqx/KX4wAn3T3
BD4HGKpFm04hyL9sWZqDyCas
=G4Vn
-----END PGP SIGNATURE-----

Received on Wednesday, 4 August 2004 17:40:56 UTC