Re: Why I moved from Forbid to Literal

Henrik Frystyk Nielsen wrote:

> Thank you for the clarification - seems to me to say that
>
> * we do allow relative URIs knowing that define them
>   within a "context"
>
> * we do define literal comparison as the fundamental
>   comparison algorithm taking into account that context

    This wording is ambiguous. You have not precisely defined the term
"context" hence it is impossible to discuss what specific meaning "taking
into account that context" means in terms of namespace name comparison. The
definition needs to be expressed as an algorithm else chaos will ensue: a
situation worse than either literal, forbid or absolutize, each of which are
expressed as an algorithm for machine consumption.

>
> I fully agree with this and I think the last part:
>
> > It seems best to me to keep 'namespace names' as just names, while
> > preserving base URI information and allowing applications to build
> > 'namespace URIs' as necessary in given contexts, typically involving
> > retrieval.
>
> can be achieved by imposing a restriction on the application *generating*
> a
> document using namespace identifiers must take into account the properties
> of the namespace that the identifiers belong to. This can be expressed as
> something like this:
>
> "An application generating a document containing namespace identifiers
> SHOULD take into account the properties of the URI space to which these
> identifiers belong. For example, if a URI space has normalization rules
> defining case-insensitivity then the generating application SHOULD NOT
> assign different semantics to two names that only differ in case."
>

    Fair enough but are you saying that an XML parser should compare
namespace names on a literal basis and that this statement is best
practices? (i.e. I agree with the above statement even though it does not
answer the question of how a namespace name parser ought behave when
building an infoset from an XML serialization.

Jonathan Borden
http://www.openhealth.org

Received on Friday, 30 June 2000 17:13:18 UTC