[
Lists Home |
Date Index |
Thread Index
]
Thank you for your note,
Jeni Tennison wrote:
>
> Hi James,
>
> You're proposing enhancing the processing that goes on in XML parsers,
> correct?
I'm observing that such enhancements are ultimately unavoidable in
namespace-aware XML processors.
> My main question is: how does the parser get to know about
> which colons in element and attribute values indicate QNames, and
> which are literal colons?
My proposal was, as you point out, insufficient to permit recognition of
literal colons. For that purpose the entity which you propose below
would be invaluable.
> For example, given:
>
> <my_document xml:qnames="resolve">
> <para type="foo:bar">
> Here: a colon that doesn't indicate a QName.
> And a literal string that looks like a QName, but isn't:
> <xmp>my:type</xmp>.
> </para>
> </my_document>
>
The example quite correctly desribes a case where an accurate
declaration of the type of the content component would be the preferred
means to ensure correct encoding and decoding of that content.
I have been arguing that declarations of this sort are unavoidable. The
response has been that they are not possible. The essential problem is
that the granularity of reference for prefixes is the character
information item, while the granularity of scope is an element. this
applies to both prefix-namespace bindings, and thus in-scope namespaces,
and to the proposed xml:qnames attribute. the xml:qnames attribute
offers only the advantage, that its implementation will not, in
addition, suffer the consequences of the mismatches in extent. There is
no way to resolve the granularity mismatch other than to correctly
declare the content. It is the reason I qualified the proposal with the
provision, that one should not expect it to be as effective as correct
declaration.
> [ a second pertinent example demonstraing how the problem manifests itself with respect to XPath expressions. ]
I had considered whether, in my earlier post, to include the assertion
that XPATH and XPATHS tokenized types were just as necessary, but
decided to forgo the effort.
>
> XML Schema deals with this partially. Elements and attributes that are
> of the type xs:QName are resolved during parsing by schema validators,
> and the resolved qualified name is passed through to the application
> in the PSVI.
>
> What XML Schema doesn't help with is dealing with XPaths or attributes
> that hold namespace prefixes (such as 'extension-element-prefixes' in
> XSLT). XML Schema can say that a value is a QName or a space-separated
> list of QNames, but it can't say that a value is an XPath, a prefix or
> a list of prefixes, or for that matter a comma-separated list of
> QNames and other uses of prefixes or QNames in values that we haven't
> thought of yet.
Which means that either the case is made that the types of such values
become primitive, or the values must be encodable in terms of
expressions of primitive types.
I am concerned about the temporal proximity of generalized entity
substitution and prefix resolution, but conjecture that the xml:qnames
attribute together with the standardized &cln; entity could be
sufficient to enable naive encoding.
> Another possibility (which I expect to get shot down immediately)
> would be to treat all colons that are not preceded or followed by
> whitespace as indications of QNames, which would mean adding a sixth
> built-in entity, &cln;, say, to escape literal colons. The examples
> above would then be:
>
> <my_document>
> <para type="foo:bar">
> Here: a colon that doesn't indicate a QName.
> And a literal string that looks like a QName, but isn't:
> <xmp>my&cln;type</xmp>.
> </para>
> </my_document>
>
> <xsl:value-of select="foo:bar/*[name() = 'fred&cln;barney']" />
>
...
|
