[dsdl-discuss] Namespaces in Schematron (was Re: Re: DIS XML for Part 3 with disposition of comments)

This is just to respond to Martin's good questions on namespaces in
Schematron (as distinct from
in SVRL).

Martin Bryan wrote:

>>ii) adding an <sch:ns> in the Schematron schema
>>
>>
>
>This is a cludge because it does not conform to the standard mechanisms for
>defining namespaces in schemas
>
>
>
This is not a kludge but is and has always been the way Schematron has
done things.

The FCD is very clear on this at s5.4.7:
"In an ISO Schematron schema, namespace prefixes in context expressions,
assertion tests and other query expressions should use the namespace
bindings provided by this element. Namespace prefixes should not use the
namespace bindings in scope for element and attribute names."

If UK body had a problem with Schematron's <ns> element, then they
should have
brought it up before! Actually, this is probably a good reason to
support having
an example using the <ns> element, as a clearer demonstration, and it is
good to have this issue
exposed.

I have taken this issue all the way to the W3C TAG (Technical
Architecture Group).

Their finding on the issue is
    http://www.w3.org/2001/tag/doc/qnameids.html
The money quote is:
"We must therefore accept that there are some applications which use
in-scope namespaces and some which use their own mechanisms."

That document, later, specifically mentions the case of XPointers as one
where
xmlns declarations are inappropriate. At one stage, the TAG even wanted
to ban Qnames
in content, which is quite bizarre and obviously unworkable.

See also the new Proposed Recommendation
    Architecture of the World Wide Web
    http://www.w3.org/TR/2004/PR-webarch-20041105/
which says, inter alia,
  "There is no single, accepted way to convert a QName into a URI or
vice versa"

The trouble with using in-scope namespaces is that then you have to support
default namespaces, which people find very confusing.

Just because James Clark decided to use the in-scope namespace
declarations in XSLT,
it does not mean that that is the XML way, or even a good way. Indeed,
XSLT 1.0
is underspecified as to how a processor knows which namespace declarations
to generate: each implementation of XLST is different in this.

I note that even XML Schemas provides two distinct syntaxes
(elementFormQualified
true or false) for how Qnames are interpreted.

> iii) adding svrl: prefix to all element Qnames in attributes.
>
>This I could agree with, but then you have to explain in detail why this
>cludge is required.
>
>
This is not a kludge but is and has always been the way Schematron has
done things.
Please note I don't mean add svrl: prefix so that test="@something"
becomes
test="@svrl:something". It is that test="schematron-output" becomes
test="svrl:schematron-output".

There is no idea of default namespaces for Qnames in Schematron: no
prefix means
no namespace. It is a furphy to think there is some concensus or
standard practise on this issue.

The Namespaces in XML specification only deals with scoping namespaces to
element and attribute names. How languages with Qnames embedded in
attribute
or element values get resolved is application-dependent. Indeed, I think
it actually
goes *against* the Namespaces in XML spec to make namespace declarations
apply to QNames. Not just the wording, but against the spirit that the
choice
of prefixes in markup is not important for the semantics of the document: a
processing system should be able to select different prefixes for
element and
attribute names to prevent name clashes. But if you use the namespace
declarations to also provide namespace-prefix bindings for things in element
and attribute values, then you need some mechanism to tell the processor
which values should be changed.

But there is no such animal.

Cheers
Rick Jelliffe

--
DSDL members discussion list
To unsubscribe, please send a message with the
command  "unsubscribe" to dsdl-discuss-request@dsdl.org
(mailto:dsdl-discuss-request@dsdl.org?Subject=unsubscribe)