Re: Simple solution? Pub. Idents. vs URN.
Martin Cottreau wrote:
> [Martin Cottreau], actually. I just quoted Paul in my original e-mail, but
> the formatting didn't make that clear. Sorry.
My fault. I snipped badly. Apologies.
> There are applications of XML that don't require FPIs, the biggest one
> simply being a replacement for HTML, so people will stop putting
> processing information in comments.
They will anyway and call it SGML. XML won't replace HTML.
It is another text type to enable the application writer or
user to choose markup. HTML will evolve on its on and so
will the users. No issue.
Simple XML with URL (for now...) and style sheets
> would solve a lot of people's problems right now.
This is so. This will happen.
> I agree we have to consider what impact not having FPI will have,
> but my gut feeling is that a) the ERB has already done this before
> deciding to drop them in the first place and b) the Web will
> evolve towards some sort of FPI mechanism.
> (wasn't that the point of the original e-mail in this thread?)
I don't think so. Evolving the Web with XML might be a
laudable result, but isn't much of a design requirement.
What I hear Debbie, Jon, Ken and others saying is that the
FPI provides functionality they need, some of which, depends
on formal registry practices and SGML Open standards for
catalogs. Does this undo the URL? Does this preclude
the use of the URL? Do the URN and the FPI/catalog conflict?
> We shouldn't try to redefine addressing on the Web: it's clear there
> are other activities within the W3C which may solve the problem.
> We have to concentrate on making XML easy and useful.
Right. However, we have on the table, the opportunity to define
hyperlinking types that do not yet exist on the Web. Part of that
task requires us to ask where the current Web initiatives are,
how XML fits with these, and how can our new definitions fit
into the existing systems as built and as proposed. XML as a
language may spawn many small applications (as is the case for
SGML) which share certain features, but are completely different
in others. Sharing the hyperlinking definitions is a plus
because they are fundamental to the controls and relationships.
> On FPI, I hope we punt.
Some of the community is saying they need these options.
Why, instead of keeping all of XMLs design under the
ERB draft, are non-normative appendixes not being prepared by those
who need this capability?
I don't know why certain options in XML are not exactly that:
optional conformance features. You have DSSSL and DSSSL-O.
HyTime has conformance options. Any good design has these
for the special case capabilities. Why not XML? Is the FPI
incompatible with Web addressing?
Further, XML is being conceived modularly. Can the modules
be separately conforming in the way SGML/DSSSL/HyTime are?
James says the FPI is hard to implement. So, it is something
not everyone should be required to implement. But this seems
to be a system implementation restriction and I don't think
we are here to restrict implementors.
Why not FPI and URL/URN/etc.?