Re: Addressing....

>If a standard format for version identification in URLs is not
>acceptable, I don't see why fragment identification is so fundamental
>that it would be acceptable.

Well, I'm on the same list as you are, and also cannot understand why
a standard version syntax is unacceptable. The scheme I propose can
handle versioning too...

>   4. Special support on servers (even CGI scripts) is frequently harder to
>deploy than special client support. Some sites are so large that running
>even the simplest CGI scripts is subject to extreme scrutiny.

Last time I checked statistics, there is an interesting counterpoint
to this: many people still use older browsers (though upgrading if
fairly frequent, it takes longer than most people think for support
for various features to bubble through). One good point of having
server-side smarts is that *all* clients can benefit.

>   6. A client will need to be able to address subdocument parts anyway --
>If linking to a 1-sentence anchor in a 2K document, it's _much_ easier to
>do local navigation than to bounce packets off a specialized server. So
>fragment IDs (or some logical equivalent will still be needed even if they
>are sometimes very sub-optimal (the 10MB document is an example).

This is the scalability problem. It get's worse when a server
interfaces to databases that *generate* XML, but don't manipulate
it. They have a harder time with faking entity boundaries.

>We can debate it all you want, but pragmatically, specialized servers are
>harder to deploy that specialized clients... I agree that in many cases
>(though not all) this is technically superior. But I just don't believe
>that such deployment will happen.

I believe that the this is not always true, though I guess that if you
have a browser that can handle XML, it would be safe to assume that it
can also support fragment id's that are XML-specific. It is less safe
to assume that all servers that send out XML, also support entities.

>>I object strenously to *requiring* that an entity be retrieved in it's
>>entirety in order to transclude a single element.
>
>I believe that this is not a requirement, see points 3, 5.

Yes, but then you assume server-side support for these cases... the
thing you are disagreeing with. Remove server-side support, and the
model becomes that of retrieving entities.

My major concern here is that if the only *standard* way of addressing
individual elements is client-side, then people will only use that,
building up momentum against finer granularity object addressing. 
It is better to establish a momentum toward superior solutions as
early as possible in order to avoid pain further down the road
(different to *requiring* superior solutions from the get-go).

>>  1) You are talking about special code in the client, which would be
>>     easily comparable to the complexity of the code in a server.
>
>Should be exactly the same, but we are putting the work on the client
>coder, who is presumably more committed to XML than a server coder, for
>whom XML is just another data format.

I think that the initial *publishers* of XML content will generally
have at least partial control over the site, as XML is going to be a
tiny niche for some time, and so will require publishers dedicated to
it's deployment. Fragment specifiers are fine for smaller documents,
but I think many initial XML publishers will be dealing with large
documents.

>>Again, I do not object to fragment specifier use, but I do object
>>to it being the only thing we can use.
>
>Special server-side URLs are always available, because a server can serve
>up anything it wants, under any URL it wants. But I don't think we can
>pretend to be able to _enforce_ server-based solutions on the web.

Sure, but if we focus on fragment specifiers to the exclusion of
server-side solutions, eventually we will have nothing but fragment
specfiers because no-one will use, or support anything different.

>>It does not scale. Worse, it
>>would preclude using XML with servers such as DynaWeb/DynaBase that
>>generate content dynamically, and may not even have the entity
>>structure left for you to address.
>    As long as you address a well-formed fragment, this should not be a
>problem. Your server can certainly be smart enough to translate address
>formats, if it is already parsing the wqhole document.

The problem is addressing this well-formed fragment you mention...

>No, but I do think that life on the high end may make it more difficult
>appreciating the limitations imposed by most server admins. We have a lot
>of work to do just convincing browser manufacturers to use XML -- if we
>don't need to sign up for more salesmanship, then we shouldn't.

Well, if we really want to improve the state of the WWW, in the long
run, servers will have to change.

BTW. When you refer to "high-end", I think you falsely make the
problem seem hard. It's trivial.

Received on Wednesday, 8 January 1997 22:59:13 UTC