- From: Pete Cordell <petexmldev@tech-know-ware.com>
- Date: Mon, 12 Mar 2007 11:40:18 -0000
- To: "Bryan Rasmussen" <BRS@itst.dk>, <xmlschema-dev@w3.org>
Hi Bryan,
I think you have very different requirements to what is being proposed here.
Your requirements are for the developer of a schema that can be extended and
who wants to answer the question "what is allowed to be inserted here?"
This proposal is for the developer of the schema that is doing the
extending, and wants to answer the question, "which xs:any does this
extension extend?"
I don't think this aspect of the wild carding issue has been considered in
XSD so far.
Regards,
Pete.
--
=============================================
Pete Cordell
Tech-Know-Ware Ltd
for XML to C++ data binding visit
http://www.tech-know-ware.com/lmx/
http://www.codalogic.com/lmx/
=============================================
----- Original Message -----
From: "Bryan Rasmussen" <BRS@itst.dk>
To: "Pete Cordell" <petexmldev@tech-know-ware.com>; <xmlschema-dev@w3.org>
Sent: Monday, March 12, 2007 10:45 AM
Subject: SV: XSD 1.1 Proposal: Naming wildcard extension sites
Well,
This may be already supported but I suppose not from what I've read and
probably in past discussion that I've missed it has been ruled out for some
reason but I think I find the whole syntax for any and namespaces sort of
confusing and at the same time not strong enough for my needs. Basically
what
I need is the ability to say I want any namespace with a particular
structure
to it, and I suppose it would be best served by using the regular
expressions
ability of XSD. My use case can be shown by looking here:
http://rep.oio.dk that is the danish national repository of namespaces
(should be RDDL, I know, but politics...)
We would find it a boon and a blessing to say that any namespace is allowed
inside of an extension element as long as it starts with rep.oio.dk.
Due to the namespace naming standards we employ I could easily see a
requirement in a particular namespace to allow any namespace that has the
same semantic domain, for example http://rep.oio.dk/skat for the tax domain
or to be able to say, in rare cases, that we allow all namespaces from
namespace X with a date pattern in their name the year of which is later
than
2005.
Cheers,
Bryan Rasmussen
-----Oprindelig meddelelse-----
Fra: xmlschema-dev-request@w3.org
[mailto:xmlschema-dev-request@w3.org]På vegne af Pete Cordell
Sendt: 10. marts 2007 19:19
Til: xmlschema-dev@w3.org
Emne: XSD 1.1 Proposal: Naming wildcard extension sites
I know it's late in the day, but I'd like to propose an addition to XSD 1.1
that could greatly enhance the control over the way in which schemas are
extended. As it was recently mentioned that XSD 1.1 can still be changed
I'm hopeful that it can be appropriately considered. I'm suggesting it here
first in the hope that the issues surrounding it can be discussed before
potentially formally proposing it as an addition for XSD 1.1.
XSD 1.1 is having important changes that allow for better extensibility.
These changes are critical as extensibility has been one of XSD 1.0's major
weaknesses, which has caused it to start losing ground to other schema
languages such as Relax-NG (see Robin Cover's XML Daily Newslink. Thursday,
08 March 2007).
However, most of these changes affect the schema that is allowing components
to be added to it.
What is missing is a way for schemas specifying extensions to be able to
specify where those extensions should be placed in the schema being
extended.
For example, the following schema specifies two locations where extensions
are allowed:
<?xml version="1.0" encoding="utf-8" ?>
<xs:schema targetNamespace="http://example.com/core.xsd"
elementFormDefault="qualified"
xmlns="http://example.com/core.xsd"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="Element1">
<xs:complexType>
<xs:sequence>
<xs:element name="Child1" type="xs:int"/>
<xs:any namespace="##other" maxOccurs="unbounded"
processContents="lax"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="Element2">
<xs:complexType>
<xs:sequence>
<xs:element name="Child2" type="xs:int"/>
<xs:any namespace="##other" maxOccurs="unbounded"
processContents="lax"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
An extension schema may specify an extension as follows:
<?xml version="1.0" encoding="utf-8" ?>
<xs:schema targetNamespace="http://example.com/extension.xsd"
elementFormDefault="qualified"
xmlns="http://example.com/extension.xsd"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="ExtensionElement" type="xs:int"/>
</xs:schema>
However, it's not clear from the extension schema which of the extension
sites in the core schema are affected. Currently the site that an extension
is applicable to is specified by narrative text. This has obvious
disadvantages including a lack of precision in the definition and the
inability of tools to be made aware of the constraints.
Hence, it is proposed that extension sites be labelled, as in the following
example:
<?xml version="1.0" encoding="utf-8" ?>
<xs:schema targetNamespace="http://example.com/core.xsd"
elementFormDefault="qualified"
xmlns="http://example.com/core.xsd"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="Element1">
<xs:complexType>
<xs:sequence>
<xs:element name="Child1" type="xs:int"/>
<xs:any namespace="##other" maxOccurs="unbounded"
processContents="lax" socket="Element1"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="Element2">
<xs:complexType>
<xs:sequence>
<xs:element name="Child2" type="xs:int"/>
<xs:any namespace="##other" maxOccurs="unbounded"
processContents="lax" socket="Element2"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
Here socket attributes have been added to the two xs:any wildcard
components, which label the extension points using NCNames.
Further it is proposed that a plugin component be defined, which is used as
follows:
<?xml version="1.0" encoding="utf-8" ?>
<xs:schema targetNamespace="http://example.com/extension.xsd"
elementFormDefault="qualified"
xmlns="http://example.com/extension.xsd"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:core="http://example.com/core.xsd">
<xs:plugin socket="core:Element1">
<xs:element name="ExtensionElement" type="xs:int"
maxOccurs="unbounded"/>
</xs:plugin>
</xs:schema>
The plugin component specifies that the contents of its children must be
logically inserted into the location preceding the wildcard that is resolved
to by the value of its socket attribute (which is a list of QNames).
Hence, after the above plugin element is applied the input core schema is
logically treated as if it were:
<?xml version="1.0" encoding="utf-8" ?>
<xs:schema targetNamespace="http://example.com/core.xsd"
elementFormDefault="qualified"
xmlns="http://example.com/core.xsd"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="Element1">
<xs:complexType>
<xs:sequence>
<xs:element name="Child1" type="xs:int"/>
<xs:element name="ExtensionElement" type="xs:int"
maxOccurs="unbounded"/> <!--but in
namespace 'extension'-->
<xs:any namespace="##other" maxOccurs="unbounded"
processContents="lax" socket="Element1"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="Element2">
<xs:complexType>
<xs:sequence>
<xs:element name="Child2" type="xs:int"/>
<xs:any namespace="##other" maxOccurs="unbounded"
processContents="lax" socket="Element2"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
Note that rather than using the ID attribute to specify the sites where
components can been plugged in, a new attribute (socket) has been
introduced. This is because the values of ID attributes must be unique
across an entire schema, whereas it may on occasion be convenient to specify
multiple plugin sites that receive the same augmented content and therefore
have the same socket name. For example, you could have a core schema such
as which has two extension sites with the same name:
<?xml version="1.0" encoding="utf-8" ?>
<xs:schema targetNamespace="http://example.com/core.xsd"
elementFormDefault="qualified"
xmlns="http://example.com/core.xsd"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="Element1">
<xs:complexType>
<xs:sequence>
<xs:element name="Child1" type="xs:int"/>
<xs:any namespace="##other" maxOccurs="unbounded"
processContents="lax" socket="Element"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="Element2">
<xs:complexType>
<xs:sequence>
<xs:element name="Child2" type="xs:int"/>
<xs:any namespace="##other" maxOccurs="unbounded"
processContents="lax" socket="Element"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
And an extension schema as:
<?xml version="1.0" encoding="utf-8" ?>
<xs:schema targetNamespace="http://example.com/extension.xsd"
elementFormDefault="qualified"
xmlns="http://example.com/extension.xsd"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:core="http://example.com/core.xsd">
<xs:plugin socket="core:Element">
<xs:element name="ExtensionElement" type="xs:int"
maxOccurs="unbounded"/>
</xs:plugin>
</xs:schema>
The logical equivalent of which would be:
<?xml version="1.0" encoding="utf-8" ?>
<xs:schema targetNamespace="http://example.com/core.xsd"
elementFormDefault="qualified"
xmlns="http://example.com/core.xsd"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="Element1">
<xs:complexType>
<xs:sequence>
<xs:element name="Child1" type="xs:int"/>
<xs:element name="ExtensionElement" type="xs:int"
maxOccurs="unbounded"/><!--but in namespace
'extension'-->
<xs:any namespace="##other" maxOccurs="unbounded"
processContents="lax" socket="Element1"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="Element2">
<xs:complexType>
<xs:sequence>
<xs:element name="Child2" type="xs:int"/>
<xs:element name="ExtensionElement" type="xs:int"
maxOccurs="unbounded"/><!--but in namespace
'extension'-->
<xs:any namespace="##other" maxOccurs="unbounded"
processContents="lax" socket="Element2"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
Similarly, it may be appropriate to plug the same content into multiple
differently named sites. Hence the type of the socket attribute in the
plugin element is a list of QNames. As such the following extension schema
can be applied to the earlier mentioned core schema with the two differently
named extension sites and yield the latter mentioned augmented logical
schema:
<?xml version="1.0" encoding="utf-8" ?>
<xs:schema targetNamespace="http://example.com/extension.xsd"
elementFormDefault="qualified"
xmlns="http://example.com/extension.xsd"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:core="http://example.com/core.xsd">
<xs:plugin socket="core:Element1 core:Element2">
<xs:element name="ExtensionElement" type="xs:int"
maxOccurs="unbounded"/>
</xs:plugin>
</xs:schema>
Attributes can be handled in the same way. For example, a schema of the
following form could be specified:
<?xml version="1.0" encoding="utf-8" ?>
<xs:schema targetNamespace="http://example.com/core.xsd"
elementFormDefault="qualified"
xmlns="http://example.com/core.xsd"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="Element1">
<xs:complexType>
<xs:sequence>
<xs:element name="Child1" type="xs:int"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"
socket="Element1"/>
</xs:complexType>
</xs:element>
</xs:schema>
with an extension schema of:
<?xml version="1.0" encoding="utf-8" ?>
<xs:schema targetNamespace="http://example.com/extension.xsd"
elementFormDefault="qualified"
xmlns="http://example.com/extension.xsd"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:core="http://example.com/core.xsd">
<xs:plugin socket="core:Element1">
<xs:attribute name="ExtensionAttribute" type="xs:int"/>
</xs:plugin>
</xs:schema>
It is proposed that the xs:any and xs:anyAttribute extension points have
separate namespaces in the same way the elements and types have different
namespaces. Hence a schema of the following form would be legal:
<?xml version="1.0" encoding="utf-8" ?>
<xs:schema targetNamespace="http://example.com/core.xsd"
elementFormDefault="qualified"
xmlns="http://example.com/core.xsd"
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="Element1">
<xs:complexType>
<xs:sequence>
<xs:element name="Child1" type="xs:int"/>
<xs:any namespace="##other" maxOccurs="unbounded"
processContents="lax" socket="Element1"/>
</xs:sequence>
<xs:anyAttribute namespace="##other" processContents="lax"
socket="Element1"/>
</xs:complexType>
</xs:element>
</xs:schema>
To implement this proposal a new schema component is required as follows:
<plugin
socket = list of QName
{any attributes from non-schema namespace}
>
Content: (xs:annotation?, (xs:element*, xs:attribute*))
</plugin>
The xs:any and xs:anyAttribute schema components need to be modified with
the addition of a socket attribute as follows (inserting the socket
attribute at the beginning of the list of attributes for clarity purposes
only):
<any
socket = NCName
id = ID
maxOccurs = (nonNegativeInteger | unbounded) : 1
minOccurs = nonNegativeInteger : 1
namespace = ((##any | ##other) | List of (anyURI | (##targetNamespace |
##local)) )
notNamespace = List of (anyURI | (##targetNamespace | ##local))
notQName = List of QName
processContents = (lax | skip | strict) : strict
{any attributes with non-schema namespace . . .}>
Content: (annotation?)
</any>
<anyAttribute
socket = NCName
id = ID
namespace = ((##any | ##other) | List of (anyURI | (##targetNamespace |
##local)) )
notNamespace = List of (anyURI | (##targetNamespace | ##local))
notQName = List of QName
processContents = (lax | skip | strict) : strict
{any attributes with non-schema namespace . . .}>
Content: (annotation?)
</anyAttribute>
In summary this is a simple proposal that allows formal specification of how
one schema extends another schema. Without such facilities such mechanisms
must typically be specified using narrative text. Such a narrative approach
obviously limits the accuracy of a schema set and does not allow tools to
understand such constraints. This proposal fixes this problem in a simple
and flexible way.
Pete.
--
=============================================
Pete Cordell
Tech-Know-Ware Ltd
for XML to C++ data binding visit
http://www.tech-know-ware.com/lmx/
http://www.codalogic.com/lmx/
=============================================
Received on Monday, 12 March 2007 11:40:44 UTC