W3C home > Mailing lists > Public > public-xml-core-wg@w3.org > April 2005

XInclude, schema validity-assessment, xml:base and xml:lang

From: Henry S. Thompson <ht@inf.ed.ac.uk>
Date: Mon, 18 Apr 2005 15:33:45 +0100
To: public-xml-core-wg <public-xml-core-wg@w3.org>
Message-ID: <f5b3bto9mt2.fsf@erasmus.inf.ed.ac.uk>

[Note that this email is Bcc'd to the member-only
 w3c-xml-schema-ig@w3.org list -- please reply to
 public-xml-core-wg@w3.org and repeat the Bcc to keep both WGs involved]

Position 1: xml:lang and xml:base should be understood as out-of-band
mechanisms for notating aspects of the infoset (the *[language]* and
*[base URI]* properties) which would otherwise be inexpressible.  As
such they are _not_ part of any specific XML application, and are
arguably in the same category as namespace declarations, that is,
using attribute syntax but not really attributes at all.  If so, it
was a mistake to treat them as attributes, and not as declarations, in
deciding how to treat them wrt XML Schema validity assessment.  We
should accordingly at least commit to removing them from the scope of
validity assessment in XML Schema 1.1, and possibly do so for XML
Schema 1.0 as well via an erratum.

I'm tempted to say that, contrary to earlier discussion, this should
be all or nothing.  That is, as proposed above, the justification for
this move is that these are _not_ really attributes.  If that's the
case, they _can't_ be visible to schema validity assessment.  Any
argument that this should just be a default, and allowing people to
take control of their assessment by explicit declarations, is
tantamount to claiming that they really _are_ attributes, and we're
just treating them specially because of the inconvenience of doing
otherwise, particularly wrt XInclude 'output'.  I find such an
argument much less compelling.

Position 2:  xml:base and xml:lang are attributes like any others.  To
make it easier to manage them, we should provide some mechanism
to make it easy to declare 'universal' attributes.

I have mixed feelings about this.  For one thing, we already have such
a mechanism.  If I define the following type:

 <xs:complexType name="nearlyAnyType">
   <xs:restriction base="xs:anyType">
     <xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
    <xs:attribute ref="xml:base"/>
    <xs:attribute ref="xml:lang"/>
    <xs:anyAttribute processContents="lax"/>

and then use it as the base for all my other type definitions, I get
the desired effect.  It would be take only a modest amount of effort
to produce a stylesheet which would transform 99.99% of all conformant
schema documents to use this approach.

I suppose we could imagine defining xs:anyType in XML Schema 1.1 to
have those two attribute declarations -- that would be a 'no new
syntax' solution, and would be over-rideable.

Harder to see that as an erratum.

Aha, so _here's_ a lightweight interim solution.

Provide a schema document at http://www.w3.org/2001/XMLSchemaXBL.xsd
as follows:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

 <xs:import namespace="http://www.w3.org/XML/1998/namespace"/>

 <xs:redefine schemaLocation="http://www.w3.org/2001/XMLSchema.xsd">
  <xs:complexType name="anyType">
    <xs:restriction base="xs:anyType">
      <xs:any processContents="lax" minOccurs="0" maxOccurs="unbounded"/>
     <xs:attribute ref="xml:base"/>
     <xs:attribute ref="xml:lang"/>
     <xs:anyAttribute processContents="lax"/>


Then if you invoke your schema processor with that schema document
alongside (before, logically) your own, the right thing will happen!

Seems to me that really is a solution we could try to sell to Oracle
and Microsoft, perhaps via a Working Group Note . . .

Once I patched XSV to not ignore all schema documents for the
XMLSchema namespace, this worked.  I've actually put the above schema
document in the advertised place, so other implementors can see if it
works with their processors. . .

Position 3: XML Core and Schema WGs issue a joint WG Note defining a
sort of XInclude-on-steriods, which is an XML application which
does the following:

 1) Runs XInclude on its 'input';
 2) Remove xml:base from the resulting infoset;
 3) (Optional) Do schema-validity assessment on the resulting infoset
    with zero or more specified schema documents;
 4) (Optional) Absolutise any relative URIs wrt the appropriate [base
    URI] value either looking for EIIs or AIIs in the resulting
    (possible PSV)infoset which
      a) Match a specified XPath
      b) (if (3) was done) match element(*,xs:anyURI) or attribute(*,xs:anyURI)
 5) Serialise the resulting infoset.

Note that (4) "does the right thing" because the XInclude REC requires
not only that xml:base be added, but also that the [base URI]
properties be updated.

 Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
                     Half-time member of W3C Team
    2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
            Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                   URL: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]
Received on Monday, 18 April 2005 14:33:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:40:28 UTC