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.?

len bullard

Received on Friday, 29 November 1996 17:40:56 UTC