Re: parseType="literal"

[Jeremy Carroll]

>
> Danny:
> >
> > The rest of the material posted makes sense to me, but I have trouble
with
> > the example below - by any (current) reckoning, surely "q:name" is just
a
> > literal string itself here (nothing can cross the quote
> > threshold), and has
> > no connection whatsoever to the earlier xmlns:q=... (without making a
> > significant revision of the XML spec)??
> >
> [ example at end ]
>
> You'd have thought so.
>
> But ... XML Schema allows qnames in attribute values e.g.
> xsi:type="xsd:decimal" where the xsd is a namespace prefix and must be
bound
> to the appropriate URI. XSLT allows XPath expressions in attribute values,
> these again use namespace prefixes as prefixes - i.e. they must be bound
to
> the right URI.
>

I always thought this made sense in context.  Get the attribute value, use
the prefix binding to match to the binding for a namespace in effect in the
context of the processing that's currrently going on.  The apparent qname
used for an attribute value, although just a stirng, is supposed to be
interpreted as a qname by the consuming application.

It seems to make sense, but only if the context is stable and consistent,
like "xsd:" in the context of running an xml schema validation check.
Notice that in xml schema, there can be only one target namespace in any one
schema document.  Also notice that in an xml schema document you'd only want
to have elements that belong, that is, in the namespace for xml schema.  And
similarly for xslt.  So there is a good measure of this stability in xmk
schema and xslt.

But in an rdf document, especially one where the rdf is mixed in with
ordinary xml markup, the namespace bound to a given prefix could possibly
change from place to place withn a document.  That might lead to confusion
and ambiguity.  You would need,it seems, the namespace binding at the point
of processing to be the same as for the attribute whose value is that qname.

Hmm, sounds tricky.

Cheers,

Tom P

Received on Tuesday, 12 March 2002 18:59:49 UTC