OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

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

RE: Namespaces, schemas, Simon's filters.

On 23 Aug 2001 13:45:46 -0700, Tim Bray wrote:
[I agree with pretty much everything up to the PS.]

> PS: And since the title line mentions Simon's filters, they look
> to me like well-done software, but I continue to believe that
> they should never be used, since they (a) fly in the face of
> the author's intent as regards namespaces, and (b) they break
> schema validation.

I could fix (b) by writing another filter which changes the schema, as
has been suggested by a few people (Richard Tobin?).  As I don't plan to
deal with W3C XML Schema directly (in my programming, at any rate), that
hasn't been an issue for me.

As far as (a) is concerned, I rarely privilege the "author's intent" if
it gets in the way of what I need to do with information.  You did a
nice job yourself of pointing out:

>A1: One of the important reasons is so that you can re-use data for
>purposes other than those envisioned by its creator.  This is why,
>in the document space, XML is an unqualifiedly better storage 
>format than ...

That said, I don't mind hoping that no one actually uses
ElementNamespaceFilter, though I mostly hope that no one has to deal
with local unqualified names.  Ditto for AnnotElementNamespaceFilter.

On the other hand, AttributeNamespaceFilter is seeing use from RDF folks
who now want to explicitly qualify their attributes.  The others are
really just utility filters, mostly handy for people dealing with
namespace versioning issues.

I'm glad they look like well-done software - what they attempt to do is
so simple that I'd be pretty well embarrassed if they weren't.  Not like
that hasn't happened before, or won't happen again.

Simon St.Laurent