XMLSCHEMA-DEV Mailing ListXML Schema-DEV is an open, un-moderated email list about W3C XML Schema (XSD) development issues, including XML Schema tools, tutorials, specifications, syntax, data modeling, and more. XMLSCHEMA-DEV is a free XML Schema learning resource to help further your XML education.Copyright 2004-2006 Progress Software Corporation. All Rights Reserved.http://www.stylusstudio.com/feeds/atom/?f=3Stylus Studiostylusstudio@stylusstudio.com2010-02-09T14:16:07ZRe: XML Zebra, a path-based tool for generating diff fingerprints for XML Schemas http://xsd.stylusstudio.com/2010Feb/post02000.htm2010-02-06T22:31:04ZVersion 1.0-pre-2 of XML Zebra is now available. It adds support for
substitution groups, and you can now set namespace prefixes via the
command line.
https://launchpad.net/xmlzebra/+announcement/5072
Cheers, Tony.
On Sun, 17 Jan 2010 21:01:38 -0000, Anthony B. Coates (W3C Lists)
<abcoatesecure-w3c@yahoo.co.uk> wrote:
> I have written a tool (in Scala) that can be used to check the
> differences
> between versions of a set of W3C XML Schemas. The tool can be run with
> Scala, Java, or Apache Ant. The idea is that for each version, you
> create
> a fingerprint file that contains paths (like XPaths, but with an extended
> syntax). By comparing the two fingerprint files for two versions, you
> can
> see what has changed between the versions of the Schemas. The tools
> makes
> use of the XMLBeans API for examining the structure of W3C XML Schemas.
>
> How does this differ from just doing diffs of the individual Schema files
> themselves? The difference is that the path-based approach shows you not
> only what has changed, but also shows all of the places that are directly
> or indirectly impacted by the change. Also, the path-based approach
> ignores restructurings that don't impact users, like renaming of Schema
> types or moving of definitions to a different Schema file. Put another
> way, the path-based approach allows you to evaluate how the Schemas have
> changed from a user-impact perspective, rather than from a simple
> file-change perspective.
>
> The software is open source, released under the Apache licence. For more
> details, and to download it, see
>
> http://www.xmlzebra.com/
>
> There will be a presentation about this software at the XML Prague 2010
> conference, 13-14 March.
>
> http://www.xmlprague.cz/2010/index.html
>
> Feedback would be very welcome. Thanks,
>
> Cheers, Tony.
--
Anthony B. Coates
Director and CTO
Londata Ltd
abcoates@londata.com
UK: +44 (20) 8816 7700, US: +1 (239) 344 7700
Mobile/Cell: +44 (79) 0543 9026
Skype: abcoates
Data standards participant: genericode, ISO 20022 (ISO 15022 XML),
UN/CEFACT, MDDL, FpML, UBL.
http://www.londata.com/
Received on Saturday, 6 February 2010 22:31:42 GMT
]]>a proposition about ID/IDREF and element optionality http://xsd.stylusstudio.com/2010Feb/post01000.htm2010-02-05T18:03:58ZA friend of mine was recently confronted with a curious claim
about XSD schemas; let us call it proposition (1):
... a schema that supports id/idref use must make all
attributes and elements optional...
This seemed implausible to them, so they consulted me, just to
make sure there was not some sub-clause of a sub-clause they had
overlooked.
I have assured them that unless there is a sub-clause of a
sub-clause which I have also overlooked, proposition (1) is
false. Now, it's not unheard of for people to make mistakes
about XSD and for false statements to circulate as a result.
But what puzzles me is that I can't think of any true statement
about XSD that might have been misunderstood in such a way
as to give rise to proposition (1).
Have any readers of this list encountered this misconception
before? Do you know how it arose?
Have any of the various "best-practices" documents which convey
advice for users of XSD suggested such a thing? Is there
some design discipline for XSD which prescribes optionality
for all things as the concomitant of ID/IDREF use (and if so,
what sects practice that discipline)?
And, of course, if you can point me to the sub-clause of a
sub-clause which makes proposition (1) true, I am eager to
be enlightened, even at the cost of public humiliation.
Thanks.
--
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com
* http://cmsmcq.com/mib
* http://balisage.net
****************************************************************
Received on Saturday, 6 February 2010 01:04:29 GMT
]]>[ANN] Xerces-C++ 3.1.0 released http://xsd.stylusstudio.com/2010Feb/post00000.htm2010-02-02T14:32:03ZHi,
I am pleased to announce the availability of Apache Xerces-C++ 3.1.0.
Xerces-C++ is an open-source, validating XML parser written in a
portable subset of C++. It provides DOM (level 1, 2, and 3), SAX,
and SAX2 APIs and supports validation of XML documents against DTD
and XML Schema.
This version includes a number of new features, performance improvements
and a large number of bug fixes, especially in the XML Schema spec
conformance area, including:
* Support for handling multiple XML Schema import declarations with
the same target namespace.
* Support for configuration of the parser buffer low water mark.
* DOMLSParser::parseWithContext implementation.
* Improved XML Schema performance and reduced memory footprint when
validating with large maxOccurs values. If available, the SSE2
instructions are used to further speedup this case.
* Improved scalability of the XML Schema identity checking (key,
keyref, and unique).
* More robust external library detection (libcurl and ICU).
* Compilation of the ICU message loader resources no longer depends
on the ICU implementation details.
For a more detailed list of changes see the official announcement:
http://marc.info/?l=xerces-c-dev&m=126502748921483&w=2
For more information on some of the new features see this blog post:
http://www.codesynthesis.com/~boris/blog/2010/02/02/xerces-cxx-3-1-0-released
This release has been tested on all major platforms and comes with
precompiled libraries (total 16) for various CPU architectures,
operating systems, and C++ compilers. For most platforms 32-bit and
64-bit variants are provided.
More information on Xerces-C++, including documentation and build
instructions, is available from the project's website:
http://xerces.apache.org/xerces-c/
The source code archives and precompiled binaries are available from
the download page:
http://xerces.apache.org/xerces-c/download.cgi
Boris
--
Boris Kolpackov, Code Synthesis http://codesynthesis.com/~boris/blog
Open-source XML data binding for C++ http://codesynthesis.com/products/xsd
XML data binding for embedded systems http://codesynthesis.com/products/xsde
Command line interface to C++ compiler http://codesynthesis.com/projects/cli
Received on Tuesday, 2 February 2010 12:32:33 GMT
]]>Re: Need something like xs:sequence without order? http://xsd.stylusstudio.com/2010Jan/post02003.htm2010-01-29T15:31:32ZThanks for your advice Noah and Michael!
2010/1/29 <noah_mendelsohn@us.ibm.com>
> Michael Kay's Saxon has support for at least much of XSD 1.1. I assume
> but do not know for a fact that it supports SAX. Michael follows this
> list, I think, so he can give you more details if you don't find them
> online.
>
> Noah
>
> --------------------------------------
> Noah Mendelsohn
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
>
>
>
>
>
>
>
>
> Felix Nensa <nensa@zeec.biz>
> 01/28/2010 07:09 PM
>
> To: noah_mendelsohn@us.ibm.com
> cc: xmlschema-dev@w3.org, xmlschema-dev-request@w3.org
> Subject: Re: Need something like xs:sequence without order?
>
>
> Thank you for your reply.
>
> In schema 1.0:
>
> <xsd:choice minOccurs="0" maxOccurs="unbounded">
> <xsd:element ref="A" />
> etc.
> ....references to A,B,C
>
> This is quite exacly what I am doing right now as a workaround.. with the
> downsides you describe.
>
> In schema 1.1:
>
> <xsd:all>
> <xsd:element ref="A" />
> [...]
> <xsd:element ref="D" minOccurs="0" maxOccurs="2>
>
> In other words, in schema 1.0, you can use choice, but you don't get to
> tightly control the number of occurrences of each named element. Schema
> 1.1 can do the same, but it also allows you to use <xsd:all> with explicit
> occurrence counts. That could enforce, for example, that you wanted at
> most two "D" elements, regardless of order with respect to the others.
> Note that XSD 1.1 is still in Candidate Recommendation status and is not
> yet widely deployed.
>
>
> Do you know if there is any validating SAX parser for java that supports
> Schema 1.1? I would like to give it a try.
>
> Thanks for your help,
>
> Felix
>
>
>
>
> Felix Nensa <nensa@zeec.biz>
> Sent by: xmlschema-dev-request@w3.org
> 01/28/2010 12:04 PM
>
> To: xmlschema-dev@w3.org
> cc: (bcc: Noah Mendelsohn/Cambridge/IBM)
> Subject: Need something like xs:sequence without order?
>
>
> Hi experts,
>
> I have some tricky XML that needs to be validated against an XSD, that I
> am not sure how to define.
> The XML could come in several variations. Some examples:
>
> Example 1:
>
> <SomeElement>
> <A>aaa</A>
> <B>bbb</B>
> <C>ccc</C>
> <D>ddd</D>
> <D>dde</D>
> </SomeElement>
>
> Example 2:
>
> <SomeElement>
> <B>bbb</B>
> <A>aaa</A>
> <C>ccc</C>
> <D>ddd</D>
> <D>dde</D>
> </SomeElement>
>
> Example 3:
>
> <SomeElement>
> <B>bbb</B>
> <A>aaa</A>
> <D>ddd</D>
> <D>dde</D>
> </SomeElement>
>
>
> The corresponding XSD that I would like to define (but of course is
> invalid) would look like this:
>
> <xs:element name="SomeElement">
> <xs:complexType>
> <xs:all>
> <xs:element name="A" type="xs:string" minOccurs="1" maxOccurs="1" />
> <xs:element name="B" type="xs:string" minOccurs="1" maxOccurs="1" />
> <xs:element name="C" type="xs:string" minOccurs="0" maxOccurs="1"
> />
> <xs:element name="D" type="xs:string" minOccurs="1"
> maxOccurs="unbounded" />
>
> </xs:all>
> </xs:complexType>
> </xs:element>
>
> Any ideas how to achive the same with valid XSD?
> Thanks in advance,
>
> Felix
>
>
>
>
Received on Friday, 29 January 2010 14:32:07 GMT
]]>Re: Need something like xs:sequence without order? http://xsd.stylusstudio.com/2010Jan/post09002.htm2010-01-29T01:09:45ZThank you for your reply.
In schema 1.0:
>
> <xsd:choice minOccurs="0" maxOccurs="unbounded">
> <xsd:element ref="A" />
> etc.
> ....references to A,B,C
>
This is quite exacly what I am doing right now as a workaround.. with the
downsides you describe.
> In schema 1.1:
>
> <xsd:all>
> <xsd:element ref="A" />
> [...]
> <xsd:element ref="D" minOccurs="0" maxOccurs="2>
>
> In other words, in schema 1.0, you can use choice, but you don't get to
> tightly control the number of occurrences of each named element. Schema
> 1.1 can do the same, but it also allows you to use <xsd:all> with explicit
> occurrence counts. That could enforce, for example, that you wanted at
> most two "D" elements, regardless of order with respect to the others.
> Note that XSD 1.1 is still in Candidate Recommendation status and is not
> yet widely deployed.
>
>
Do you know if there is any validating SAX parser for java that supports
Schema 1.1? I would like to give it a try.
Thanks for your help,
Felix
>
>
> Felix Nensa <nensa@zeec.biz>
> Sent by: xmlschema-dev-request@w3.org
> 01/28/2010 12:04 PM
>
> To: xmlschema-dev@w3.org
> cc: (bcc: Noah Mendelsohn/Cambridge/IBM)
> Subject: Need something like xs:sequence without order?
>
>
> Hi experts,
>
> I have some tricky XML that needs to be validated against an XSD, that I
> am not sure how to define.
> The XML could come in several variations. Some examples:
>
> Example 1:
>
> <SomeElement>
> <A>aaa</A>
> <B>bbb</B>
> <C>ccc</C>
> <D>ddd</D>
> <D>dde</D>
> </SomeElement>
>
> Example 2:
>
> <SomeElement>
> <B>bbb</B>
> <A>aaa</A>
> <C>ccc</C>
> <D>ddd</D>
> <D>dde</D>
> </SomeElement>
>
> Example 3:
>
> <SomeElement>
> <B>bbb</B>
> <A>aaa</A>
> <D>ddd</D>
> <D>dde</D>
> </SomeElement>
>
>
> The corresponding XSD that I would like to define (but of course is
> invalid) would look like this:
>
> <xs:element name="SomeElement">
> <xs:complexType>
> <xs:all>
> <xs:element name="A" type="xs:string" minOccurs="1" maxOccurs="1" />
> <xs:element name="B" type="xs:string" minOccurs="1" maxOccurs="1" />
> <xs:element name="C" type="xs:string" minOccurs="0" maxOccurs="1"
> />
> <xs:element name="D" type="xs:string" minOccurs="1"
> maxOccurs="unbounded" />
>
> </xs:all>
> </xs:complexType>
> </xs:element>
>
> Any ideas how to achive the same with valid XSD?
> Thanks in advance,
>
> Felix
>
>
Received on Friday, 29 January 2010 00:10:14 GMT
]]>RE: Need something like xs:sequence without order? http://xsd.stylusstudio.com/2010Jan/post00003.htm2010-01-29T00:40:08Z
Do you know if there is any validating SAX parser for java that supports
Schema 1.1? I would like to give it a try.
These features of the XSD 1.1 specification are supported in Saxon-EE 9.2.
(Saxon isn't actually an XML parser, but its schema validator will validate
the event stream produced by any SAX parser).
Regards,
Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay
Received on Friday, 29 January 2010 00:40:40 GMT
]]>Re: Need something like xs:sequence without order? http://xsd.stylusstudio.com/2010Jan/post01003.htm2010-01-28T20:56:27ZMichael Kay's Saxon has support for at least much of XSD 1.1. I assume
but do not know for a fact that it supports SAX. Michael follows this
list, I think, so he can give you more details if you don't find them
online.
Noah
--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------
Felix Nensa <nensa@zeec.biz>
01/28/2010 07:09 PM
To: noah_mendelsohn@us.ibm.com
cc: xmlschema-dev@w3.org, xmlschema-dev-request@w3.org
Subject: Re: Need something like xs:sequence without order?
Thank you for your reply.
In schema 1.0:
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element ref="A" />
etc.
....references to A,B,C
This is quite exacly what I am doing right now as a workaround.. with the
downsides you describe.
In schema 1.1:
<xsd:all>
<xsd:element ref="A" />
[...]
<xsd:element ref="D" minOccurs="0" maxOccurs="2>
In other words, in schema 1.0, you can use choice, but you don't get to
tightly control the number of occurrences of each named element. Schema
1.1 can do the same, but it also allows you to use <xsd:all> with explicit
occurrence counts. That could enforce, for example, that you wanted at
most two "D" elements, regardless of order with respect to the others.
Note that XSD 1.1 is still in Candidate Recommendation status and is not
yet widely deployed.
Do you know if there is any validating SAX parser for java that supports
Schema 1.1? I would like to give it a try.
Thanks for your help,
Felix
Felix Nensa <nensa@zeec.biz>
Sent by: xmlschema-dev-request@w3.org
01/28/2010 12:04 PM
To: xmlschema-dev@w3.org
cc: (bcc: Noah Mendelsohn/Cambridge/IBM)
Subject: Need something like xs:sequence without order?
Hi experts,
I have some tricky XML that needs to be validated against an XSD, that I
am not sure how to define.
The XML could come in several variations. Some examples:
Example 1:
<SomeElement>
<A>aaa</A>
<B>bbb</B>
<C>ccc</C>
<D>ddd</D>
<D>dde</D>
</SomeElement>
Example 2:
<SomeElement>
<B>bbb</B>
<A>aaa</A>
<C>ccc</C>
<D>ddd</D>
<D>dde</D>
</SomeElement>
Example 3:
<SomeElement>
<B>bbb</B>
<A>aaa</A>
<D>ddd</D>
<D>dde</D>
</SomeElement>
The corresponding XSD that I would like to define (but of course is
invalid) would look like this:
<xs:element name="SomeElement">
<xs:complexType>
<xs:all>
<xs:element name="A" type="xs:string" minOccurs="1" maxOccurs="1" />
<xs:element name="B" type="xs:string" minOccurs="1" maxOccurs="1" />
<xs:element name="C" type="xs:string" minOccurs="0" maxOccurs="1"
/>
<xs:element name="D" type="xs:string" minOccurs="1"
maxOccurs="unbounded" />
</xs:all>
</xs:complexType>
</xs:element>
Any ideas how to achive the same with valid XSD?
Thanks in advance,
Felix
Received on Friday, 29 January 2010 01:57:05 GMT
]]>Need something like xs:sequence without order? http://xsd.stylusstudio.com/2010Jan/post07002.htm2010-01-28T18:04:19ZHi experts,
I have some tricky XML that needs to be validated against an XSD, that I am
not sure how to define.
The XML could come in several variations. Some examples:
Example 1:
<SomeElement>
<A>aaa</A>
<B>bbb</B>
<C>ccc</C>
<D>ddd</D>
<D>dde</D>
</SomeElement>
Example 2:
<SomeElement>
<B>bbb</B>
<A>aaa</A>
<C>ccc</C>
<D>ddd</D>
<D>dde</D>
</SomeElement>
Example 3:
<SomeElement>
<B>bbb</B>
<A>aaa</A>
<D>ddd</D>
<D>dde</D>
</SomeElement>
The corresponding XSD that I would like to define (but of course is invalid)
would look like this:
<xs:element name="SomeElement">
<xs:complexType>
<xs:all>
<xs:element name="A" type="xs:string" minOccurs="1" maxOccurs="1" />
<xs:element name="B" type="xs:string" minOccurs="1" maxOccurs="1" />
<xs:element name="C" type="xs:string" minOccurs="0" maxOccurs="1" />
<xs:element name="D" type="xs:string" minOccurs="1"
maxOccurs="unbounded" />
</xs:all>
</xs:complexType>
</xs:element>
Any ideas how to achive the same with valid XSD?
Thanks in advance,
Felix
Received on Thursday, 28 January 2010 21:35:55 GMT
]]>Re: Need something like xs:sequence without order? http://xsd.stylusstudio.com/2010Jan/post08002.htm2010-01-28T17:31:17ZIn schema 1.0:
<xsd:choice minOccurs="0" maxOccurs="unbounded">
<xsd:element ref="A" />
etc.
....references to A,B,C
In schema 1.1:
<xsd:all>
<xsd:element ref="A" />
[...]
<xsd:element ref="D" minOccurs="0" maxOccurs="2>
In other words, in schema 1.0, you can use choice, but you don't get to
tightly control the number of occurrences of each named element. Schema
1.1 can do the same, but it also allows you to use <xsd:all> with explicit
occurrence counts. That could enforce, for example, that you wanted at
most two "D" elements, regardless of order with respect to the others.
Note that XSD 1.1 is still in Candidate Recommendation status and is not
yet widely deployed.
Noah
--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------
Felix Nensa <nensa@zeec.biz>
Sent by: xmlschema-dev-request@w3.org
01/28/2010 12:04 PM
To: xmlschema-dev@w3.org
cc: (bcc: Noah Mendelsohn/Cambridge/IBM)
Subject: Need something like xs:sequence without order?
Hi experts,
I have some tricky XML that needs to be validated against an XSD, that I
am not sure how to define.
The XML could come in several variations. Some examples:
Example 1:
<SomeElement>
<A>aaa</A>
<B>bbb</B>
<C>ccc</C>
<D>ddd</D>
<D>dde</D>
</SomeElement>
Example 2:
<SomeElement>
<B>bbb</B>
<A>aaa</A>
<C>ccc</C>
<D>ddd</D>
<D>dde</D>
</SomeElement>
Example 3:
<SomeElement>
<B>bbb</B>
<A>aaa</A>
<D>ddd</D>
<D>dde</D>
</SomeElement>
The corresponding XSD that I would like to define (but of course is
invalid) would look like this:
<xs:element name="SomeElement">
<xs:complexType>
<xs:all>
<xs:element name="A" type="xs:string" minOccurs="1" maxOccurs="1" />
<xs:element name="B" type="xs:string" minOccurs="1" maxOccurs="1" />
<xs:element name="C" type="xs:string" minOccurs="0" maxOccurs="1"
/>
<xs:element name="D" type="xs:string" minOccurs="1"
maxOccurs="unbounded" />
</xs:all>
</xs:complexType>
</xs:element>
Any ideas how to achive the same with valid XSD?
Thanks in advance,
Felix
Received on Thursday, 28 January 2010 22:31:53 GMT
]]>Re: XSD to extend a "closed" schema http://xsd.stylusstudio.com/2010Jan/post06002.htm2010-01-19T11:03:06ZYou may look also into NVDL. That allows validating the configuration
file without your additional attributes against the initial schema and
you can allow or validate your attributes against a schema that defines
them.
A sample NVDL script that validates the configuration file and allows
your attributes is below
<?xml version="1.0" encoding="UTF-8"?>
<rules xmlns="http://purl.oclc.org/dsdl/nvdl/ns/structure/1.0">
<anyNamespace>
<validate schema="official.xsd">
<mode>
<namespace ns="http://www.example.com/myeditor" match="attributes">
<allow/>
</namespace>
<anyNamespace><attach/></anyNamespace>
</mode>
</validate>
</anyNamespace>
</rules>
Best Regards,
George
--
George Cristian Bina
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
http://www.oxygenxml.com
sweavo wrote:
>
>
> George Cristian Bina-2 wrote:
>> You can just use PIs and keep the schema as it is.
>>
>> For example instead of
>>
>> <official:configitem official:name="a_name" myeditor:x="100"
>> myeditor:y="100"
>> myeditor:colour="red"><official:childelement....></official:configitem>
>>
>> you can have:
>>
>> <?myeditor x=100 y=100 colour="red"?>
>> <official:configitem official:name="a_name">
>> <official:childelement....>
>> </official:configitem>
>>
>
> Thanks for the suggestion. This could end up being a suitable workaround.
> But really it is not an ideal solution because the myeditor:x and y
> attributes really do belong to the dom node; as a PI they are a sibling in
> the DOM and rely on third parties maintaining the sequence and not putting
> additional elements in between.
Received on Tuesday, 19 January 2010 09:03:35 GMT
]]>Re: XSD to extend a "closed" schema http://xsd.stylusstudio.com/2010Jan/post04002.htm2010-01-19T08:16:06ZYou can just use PIs and keep the schema as it is.
For example instead of
<official:configitem official:name="a_name" myeditor:x="100"
myeditor:y="100"
myeditor:colour="red"><official:childelement....></official:configitem>
you can have:
<?myeditor x=100 y=100 colour="red"?>
<official:configitem official:name="a_name">
<official:childelement....>
</official:configitem>
Best Regards,
George
--
George Cristian Bina
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
http://www.oxygenxml.com
sweavo wrote:
> Hi All,
>
> Apologies if this has been done to death, I'm not even sure of what search
> terms might help me here. I've googled and read around but seem to be stuck.
>
> I have a schema (that I'm not allowed to edit) that specifies how
> configuration files should be laid out. From time to time I receive an
> update from the committee in charge and the new version must be used.
>
> I have written several tools for editing these config files, and it would be
> nice to embed information in the XML (instance document) for the tools to
> use when manipulating the XML. So I'm looking for the file to contain
> something like:
>
> <official:configitem official:name="a_name" myeditor:x="100"
> myeditor:y="100"
> myeditor:colour="red"><official:childelement....></official:configitem>
>
> I have googled and read several pages and it looks like I can only do this
> if the type definitions in the official XSD include an anyAttribute
> declaration (unfortunately that declaration is not present in the official
> XSD).
>
> Can anyone confirm or deny whether this is true?
>
> Or is there a way for me to declare in the myeditor XSD that attribute x can
> be applied to any element in the official namespace...?
>
> Thanks in advance...
>
Received on Tuesday, 19 January 2010 06:16:37 GMT
]]>Re: XSD to extend a "closed" schema http://xsd.stylusstudio.com/2010Jan/post05002.htm2010-01-19T00:42:33Z
George Cristian Bina-2 wrote:
>
> You can just use PIs and keep the schema as it is.
>
> For example instead of
>
> <official:configitem official:name="a_name" myeditor:x="100"
> myeditor:y="100"
> myeditor:colour="red"><official:childelement....></official:configitem>
>
> you can have:
>
> <?myeditor x=100 y=100 colour="red"?>
> <official:configitem official:name="a_name">
> <official:childelement....>
> </official:configitem>
>
Thanks for the suggestion. This could end up being a suitable workaround.
But really it is not an ideal solution because the myeditor:x and y
attributes really do belong to the dom node; as a PI they are a sibling in
the DOM and rely on third parties maintaining the sequence and not putting
additional elements in between.
--
View this message in context: http://old.nabble.com/XSD-to-extend-a-%22closed%22-schema-tp27212594p27222526.html
Sent from the w3.org - xmlschema-devmailing list archive at Nabble.com.
Received on Tuesday, 19 January 2010 08:43:04 GMT
]]>XSD Unit testing http://xsd.stylusstudio.com/2010Jan/post02002.htm2010-01-18T11:45:40ZHi there,
What are people using for doing XSD unit testing ? Has anyone used SUT ?
Ref:
http://sut.sf.net
Thanks for comments,
--
Mathieu
Received on Monday, 18 January 2010 10:46:32 GMT
]]>Re: url versus urn for namespace uri? http://xsd.stylusstudio.com/2010Jan/post01002.htm2010-01-18T10:23:05Z-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Some of the reasoning behind the W3C recommendation that you should
not only use an http: URI to identify your namespaces, but that you
also document your namespace at that URI (the policy which Michale Kay
disagress with) can be found at
http://www.w3.org/TR/webarch/#namespace-document
A more extended discussion of the value for the Web of including in
such a document machine-readable information such as provided by RDDL
or GRDDL, see also
http://www.w3.org/2001/tag/doc/selfDescribingDocuments
ht
- --
Henry S. Thompson, School of Informatics, University of Edinburgh
Half-time member of W3C Team
10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 651-1426, 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]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFLVDaJkjnJixAXWBoRAgQ4AJ0VbjZc9Ngm2hjOO+KiM0timzVq3ACfdp7h
A5c0mAspGJJ/s4D1jgKwtgs=
=+f4P
-----END PGP SIGNATURE-----
Received on Monday, 18 January 2010 10:23:35 GMT
]]>RE: url versus urn for namespace uri? http://xsd.stylusstudio.com/2010Jan/post00002.htm2010-01-18T09:49:13Z> 1) Are there any pros and cons for using a URN for a
> namespace URI? It seems that most people use URLs but I feel
> like that adds to the confusion with people expecting that
> URL to have something there if you go to it with a web browser.
Some people like to use a namespace URI that can be dereferenced to locate a
"namespace document" of some kind. This is standard practice in W3C, for
example.
In my mind this represents a gross confusion: a URI should uniquely identify
a single thing, and using the same URI to identify a namespace as well as a
document containing a human-readable or machine-readable description of the
namespace is a cheat. It's confusing the thing with a document describing
the thing. But it's an established convention, so who am I to argue?
The rot of using URIs starting with "http" set in a long time ago, and it's
probably best to just swim with the tide.
Regards,
Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay
Received on Monday, 18 January 2010 09:49:42 GMT
]]>XSD to extend a "closed" schema http://xsd.stylusstudio.com/2010Jan/post03002.htm2010-01-18T08:02:31ZHi All,
Apologies if this has been done to death, I'm not even sure of what search
terms might help me here. I've googled and read around but seem to be stuck.
I have a schema (that I'm not allowed to edit) that specifies how
configuration files should be laid out. From time to time I receive an
update from the committee in charge and the new version must be used.
I have written several tools for editing these config files, and it would be
nice to embed information in the XML (instance document) for the tools to
use when manipulating the XML. So I'm looking for the file to contain
something like:
<official:configitem official:name="a_name" myeditor:x="100"
myeditor:y="100"
myeditor:colour="red"><official:childelement....></official:configitem>
I have googled and read several pages and it looks like I can only do this
if the type definitions in the official XSD include an anyAttribute
declaration (unfortunately that declaration is not present in the official
XSD).
Can anyone confirm or deny whether this is true?
Or is there a way for me to declare in the myeditor XSD that attribute x can
be applied to any element in the official namespace...?
Thanks in advance...
--
View this message in context: http://old.nabble.com/XSD-to-extend-a-%22closed%22-schema-tp27212594p27212594.html
Sent from the w3.org - xmlschema-devmailing list archive at Nabble.com.
Received on Tuesday, 19 January 2010 00:03:17 GMT
]]>XML Zebra, a path-based tool for generating diff fingerprints for XML Schemas http://xsd.stylusstudio.com/2010Jan/post08001.htm2010-01-17T21:01:38ZI have written a tool (in Scala) that can be used to check the differences
between versions of a set of W3C XML Schemas. The tool can be run with
Scala, Java, or Apache Ant. The idea is that for each version, you create
a fingerprint file that contains paths (like XPaths, but with an extended
syntax). By comparing the two fingerprint files for two versions, you can
see what has changed between the versions of the Schemas. The tools makes
use of the XMLBeans API for examining the structure of W3C XML Schemas.
How does this differ from just doing diffs of the individual Schema files
themselves? The difference is that the path-based approach shows you not
only what has changed, but also shows all of the places that are directly
or indirectly impacted by the change. Also, the path-based approach
ignores restructurings that don't impact users, like renaming of Schema
types or moving of definitions to a different Schema file. Put another
way, the path-based approach allows you to evaluate how the Schemas have
changed from a user-impact perspective, rather than from a simple
file-change perspective.
The software is open source, released under the Apache licence. For more
details, and to download it, see
http://www.xmlzebra.com/
There will be a presentation about this software at the XML Prague 2010
conference, 13-14 March.
http://www.xmlprague.cz/2010/index.html
Feedback would be very welcome. Thanks,
Cheers, Tony.
--
Anthony B. Coates
Director and CTO
Londata Ltd
abcoates@londata.com
UK: +44 (20) 8816 7700, US: +1 (239) 344 7700
Mobile/Cell: +44 (79) 0543 9026
Skype: abcoates
Data standards participant: genericode, ISO 20022 (ISO 15022 XML),
UN/CEFACT, MDDL, FpML, UBL.
http://www.londata.com/
Received on Sunday, 17 January 2010 21:02:12 GMT
]]>url versus urn for namespace uri? http://xsd.stylusstudio.com/2010Jan/post09001.htm2010-01-16T23:49:07Z1) Are there any pros and cons for using a URN for a namespace URI? It seems that most people use URLs but I feel like that adds to the confusion with people expecting that URL to have something there if you go to it with a web browser.
2) If it doesn't matter, is there documentation for the accepted conventions for a schema namespace URN? Mine starts with the following.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ds="urn:publicid:xmlns:objecteffects-com:schema:dataset"
targetNamespace="urn:publicid:xmlns:objecteffects-com:schema:dataset"
xsi:schemaLocation="
http://www.w3.org/2001/XMLSchema
http://www.w3.org/2001/XMLSchema.xsd"
elementFormDefault="qualified"
version="1.0">
<xs:element
name="dataset"
type="ds:DatasetType"
/>
Thanks
Received on Monday, 18 January 2010 09:25:37 GMT
]]>RE: Is this schema legal? http://xsd.stylusstudio.com/2010Jan/post07001.htm2010-01-15T23:56:07Z> The schema below has two definitions for the tag "spice", one
> nested inside the other. Is that allowed?
Yes.
>
> And, could someone point me at something that answers this
> question. I tried searching the XML Schema specs at w3.org,
> but could not find anything definite.
You won't find rules in the spec that say something is allowed. You'll only
find rules saying what isn't allowed. If there's no rule prohibiting it,
then it's allowed.
Regards,
Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay
Received on Friday, 15 January 2010 23:56:36 GMT
]]>Is this schema legal? http://xsd.stylusstudio.com/2010Jan/post06001.htm2010-01-15T15:45:42ZI think this is a schema question, but it also might be an XML
namespaces question.
The schema below has two definitions for the tag "spice", one
nested inside the other. Is that allowed? I would have thought
that you can have only one definition for a name within a given
namespace. But, is it possible that it's OK in this case because
one is in a nested scope?
And, could someone point me at something that answers this
question. I tried searching the XML Schema specs at w3.org, but
could not find anything definite. The closest thing I could find
was the following:
A {scope} of global identifies element declarations available
for use in content models throughout the schema. Locally scoped
declarations are available for use only within the complex type
identified by the {scope} property. This property is *absent* in
the case of declarations within named model groups: their scope is
determined when they are used in the construction of complex type
definitions. (http://www.w3.org/TR/xmlschema-1/#cElement_Declarations)
But, it's really saying something about *scope*, not about whether
whether a name must be unique within a namespace.
And, I'm asking this question because I need to know whether
generateDS.py (a tool that that I work on and that generates
Python bindings/classes from an XML schema) should handle
this situation.
Any guidance will be appreciated.
Here's the schema:
# ============================================
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified"
>
<xs:element name="recipe">
<xs:complexType>
<xs:sequence>
<xs:element name="flour" type="flourType" />
<xs:element name="spice">
<xs:complexType>
<xs:sequence>
<xs:element name="spice">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:length value="10"/>
</xs:restriction>
</xs:simpleType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:complexType name="flourType">
<xs:sequence>
<xs:element name="style" type= "xs:string" />
<xs:element name="grade" type= "xs:integer" />
</xs:sequence>
</xs:complexType>
</xs:schema>
# ============================================
- Dave
--
Dave Kuhlman
http://www.rexx.com/~dkuhlman
Received on Friday, 15 January 2010 23:46:16 GMT
]]>Re: help with xsd http://xsd.stylusstudio.com/2010Jan/post04001.htm2010-01-15T12:12:36ZApollo,
Our XSD introduction at:
http://www.codalogic.com/lmx/xsd-overview.html
may help if you are just beginning.
Pete Cordell
Codalogic Ltd
Interface XML to C++ the easy way using XML C++
data binding to convert XSD schemas to C++ classes.
Visit http://codalogic.com/lmx/ or http://www.xml2cpp.com
for more info
----- Original Message From: "apollo"
>
> Hi
>
> I am a new-user of xsd, and at the moment I got confusing with some stuff
> Could someone please correct me if we can declare something like:
>
> <xsd:sequence>
> <xsd:element name="var_name" type="xsd:string"/>
>
> <!-- this means optional. which is similar to
> <xsd:element name="var_name" type="xsd:string" use="optional"/>
> -->
>
> <xsd:element name="var_value" type="xsd:integer" use="required"/>
> </xsd:sequence>
>
> In some stuff, it is mentioned that 'use="optional/required" ' can be
> added to attribute only. but elements are instances of attributes . Is
> this correct?
>
> Thanks for reply
>
>
>
>
Received on Friday, 15 January 2010 12:13:24 GMT
]]>xsd2dia or xsd2dot (graphviz) http://xsd.stylusstudio.com/2010Jan/post03001.htm2010-01-15T10:42:19ZHi there,
[Sorry if this slightly of topic, but I could not find better mailing
list for this question]
I am looking for a tool to convert an XSD Schema to a dia type
output or a graphviz output (dot format). Does anyone know smothing like that ?
Thanks !
--
Mathieu
Received on Friday, 15 January 2010 09:43:12 GMT
]]>RE: help with xsd http://xsd.stylusstudio.com/2010Jan/post02001.htm2010-01-15T09:29:33Z>
> I am a new-user of xsd, and at the moment I got confusing
> with some stuff Could someone please correct me if we can
> declare something like:
>
> <xsd:sequence>
> <xsd:element name="var_name" type="xsd:string"/>
>
> <!-- this means optional. which is similar to <xsd:element
> name="var_name" type="xsd:string" use="optional"/>
> -->
>
> <xsd:element name="var_value" type="xsd:integer"
> use="required"/> </xsd:sequence>
>
> In some stuff, it is mentioned that 'use="optional/required"
> ' can be added to attribute only. but elements are instances
> of attributes . Is this correct?
>
There are many differences in the way attributes and elements are described
in XML Schema (probably more differences than are strictly necessary).
With attributes, you use use="optional|required" to indicate optionality.
With elements, you use minOccurs="0|1|....". The difference of course is
that elements can appear more than once, so it's possible to say things such
as minOccurs="4", though this rarely arises in practice.
Regards,
Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay
Received on Friday, 15 January 2010 09:30:01 GMT
]]>RE: Trying to create generic schema http://xsd.stylusstudio.com/2010Jan/post01001.htm2010-01-15T09:25:37ZThere's no right answer to this. The generic coding imposes fewer
constraints on what can appear in the data, which is both good and bad.
Raising the level of abstraction in your design will tend to make the design
more versatile and more capable of dealing with requirements changing, at
the expense of being more complex and harder to work with. If you take it to
extremes you get to coding schemes like HL7 that appear to have raised the
level of abstraction to a point where the information is totally
incomprehensible to everyone except a few high priests.
XML is extensible and it's not wrong to take advantage of the fact that the
tagset can be extended. It is wrong, however, to capture "data" (as distinct
from metadata) in the tag names. But it's a very fine line between
<mobile-phone>07778887777</mobile-phone>
<phone role="mobile">07778887777</phone>
<attribute name="mobile-phone" value="07778887777"/>
Your decision.
Regards,
Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay
_____
From: xmlschema-dev-request@w3.org [mailto:xmlschema-dev-request@w3.org] On
Behalf Of Jeff Faath
Sent: 14 January 2010 19:34
To: xmlschema-dev@w3.org
Subject: Trying to create generic schema
Greetings,
I have a general question about creating a schema that is generic (from the
business point of view) vs non-generic. I was wondering if I could get
advice from experts on the advantages or pitfalls of these two methods. I'm
inexperienced with building XML documents so I don't have the foresight I
would like to have. One method might look nicer now, but I'm worried it
might have issues with future processing and extendability needs. The
question is probably best explained with an example.
We have multiple client applications that send data readings to a central
processor. The context of the readings differ based on which application it
came from. We anticipate having more applications in the future that send
more contextual data. The schema is more complicated than this, but this
sums up the issue:
Generic
<root>
<data type="appA">
<reading>X</reading>
<reading>Y</reading>
</data>
<data type="appB">
<reading>1</reading>
<reading>2</reading>
</data>
<root>
Non-generic
<root>
<appAdata>
<appAreading>X</appAreading>
<appAreading>Y</appAreading>
</appAdata>
<appBdata>
<appBreading>1</appBreading>
<appBreading>2</appBreading>
</appBdata>
<root>
In the first example, the schema is much simpler with just three elements.
The type of data is determined by the 'type' attribute and that allows for
understanding the context of the reading values. Having a new app installed
in the system would not require changing the schema.
In the second example, there are elements for each app and corresponding
readings. The context is found in the explicit elements. Adding a new app
would require adding a new element to the schema (and re-generating binding
classes).
The first example seems so much nicer, but I can't help but think there may
be some pitfalls to keeping it so clean. The second example seems verbose,
but being explicit leaves no room for doubt when processing. Might anyone
have some insight in how to go about this? Is there some middle ground
between the two methods?
Regards,
JF
Received on Friday, 15 January 2010 09:26:07 GMT
]]>Re: Trying to create generic schema http://xsd.stylusstudio.com/2010Jan/post05001.htm2010-01-15T05:29:20Z
Pros and cons of both solutions are discussed in "Strong- vs weak- typing for
features":
https://www.seegrid.csiro.au/twiki/bin/view/AppSchemas/StrongWeakTyping
https://www.seegrid.csiro.au/twiki/bin/view/AppSchemas/StrongWeakTyping
You may find these considerations helpful.
Regards,
KFF
Jeff Faath-3 wrote:
>
> Greetings,
>
> I have a general question about creating a schema that is generic (from
> the
> business point of view) vs non-generic. (...)
>
> Regards,
>
> JF
>
>
--
View this message in context: http://old.nabble.com/Trying-to-create-generic-schema-tp27174236p27175066.html
Sent from the w3.org - xmlschema-devmailing list archive at Nabble.com.
Received on Friday, 15 January 2010 13:29:50 GMT
]]>help with xsd http://xsd.stylusstudio.com/2010Jan/post00001.htm2010-01-15T03:14:31ZHi
I am a new-user of xsd, and at the moment I got confusing with some stuff
Could someone please correct me if we can declare something like:
<xsd:sequence>
<xsd:element name="var_name" type="xsd:string"/>
<!-- this means optional. which is similar to
<xsd:element name="var_name" type="xsd:string" use="optional"/>
-->
<xsd:element name="var_value" type="xsd:integer" use="required"/>
</xsd:sequence>
In some stuff, it is mentioned that 'use="optional/required" ' can be
added to attribute only. but elements are instances of attributes . Is
this correct?
Thanks for reply
Received on Friday, 15 January 2010 08:58:01 GMT
]]>Trying to create generic schema http://xsd.stylusstudio.com/2010Jan/post09000.htm2010-01-14T13:34:19ZGreetings,
I have a general question about creating a schema that is generic (from the
business point of view) vs non-generic. I was wondering if I could get
advice from experts on the advantages or pitfalls of these two methods. I'm
inexperienced with building XML documents so I don't have the foresight I
would like to have. One method might look nicer now, but I'm worried it
might have issues with future processing and extendability needs. The
question is probably best explained with an example.
We have multiple client applications that send data readings to a central
processor. The context of the readings differ based on which application it
came from. We anticipate having more applications in the future that send
more contextual data. The schema is more complicated than this, but this
sums up the issue:
Generic
<root>
<data type="appA">
<reading>X</reading>
<reading>Y</reading>
</data>
<data type="appB">
<reading>1</reading>
<reading>2</reading>
</data>
<root>
Non-generic
<root>
<appAdata>
<appAreading>X</appAreading>
<appAreading>Y</appAreading>
</appAdata>
<appBdata>
<appBreading>1</appBreading>
<appBreading>2</appBreading>
</appBdata>
<root>
In the first example, the schema is much simpler with just three elements.
The type of data is determined by the 'type' attribute and that allows for
understanding the context of the reading values. Having a new app installed
in the system would not require changing the schema.
In the second example, there are elements for each app and corresponding
readings. The context is found in the explicit elements. Adding a new app
would require adding a new element to the schema (and re-generating binding
classes).
The first example seems so much nicer, but I can't help but think there may
be some pitfalls to keeping it so clean. The second example seems verbose,
but being explicit leaves no room for doubt when processing. Might anyone
have some insight in how to go about this? Is there some middle ground
between the two methods?
Regards,
JF
Received on Friday, 15 January 2010 08:58:00 GMT
]]>RE: Extending "choice" model group in a xsd schema http://xsd.stylusstudio.com/2010Jan/post08000.htm2010-01-13T01:24:58ZMichael Kay wrote:
>
>
> Derivation by extension allows you to create a type that allows the
> original
> content, with new content added at the end. It doesn't allow any other
> modification that produces content models which the original type won't
> accept.
>
That's exactly the situation i am into, now. I am trying to extend an
already published (3rd party) xsd. And one of the difficulties is trying to
extend it in such a way that the new order makes sense. Not easy to achieve
for the reason you mentioned.
To overcome this, i was thinking of trying to do a "redefine" of the
element. But then again, apart from other rules, redefinition needs to be an
"extension" (or restriction) of the original.
Later down this mail discussion, there's a suggestion of using named model
group for creating a composite element instead of going for inheritance. But
that would require the original xsd to be composed of (reusable) named model
groups.
--
View this message in context: http://old.nabble.com/Extending-%22choice%22-model-group-in-a-xsd-schema-tp26967149p27141856.html
Sent from the w3.org - xmlschema-devmailing list archive at Nabble.com.
Received on Wednesday, 13 January 2010 09:25:26 GMT
]]>Re: Extending "choice" model group in a xsd schema http://xsd.stylusstudio.com/2010Jan/post07000.htm2010-01-13T01:17:59Z
Kevin Braun wrote:
>
> On 12/28/2009 9:28 AM, Jaikiran Pai wrote:
>> (red | blue)* (dark-red | dark-blue)*
>
> What you actually have is:
> (red | blue)+ (dark-red | dark-blue)+
>
> Your choice groups don't have minOccurs=0.
>
Hmm, i apparently misunderstood the cardinality of "choice". I was referring
to this article
http://www.oracle.com/technology/pub/articles/srivastava_structures.html
which says:
" Choice - (a | b)* - means that from the set of child elements declared
within the choice model group exactly one element must occur in the
corresponding XML-instance. The cardinality of a choice model group can
range from 0 to unbounded. A choice model group can futher contain a
sequence or a choice model group recursively."
It's the (a | b) * which misled me.
Kevin Braun wrote:
>
> If you are after (red | blue | dark-red | dark-blue)+, you aren't going
> to achieve it the way you are going. Walmsley suggests using
> substitution groups to extend choice groups (see 19.5.2 Extensions for
> Choice Groups, in Definitive XML Schema). You might take a look at that
> approach and see if it meets your needs.
>
Thanks Kevin, looking forward to get a copy of that one.
--
View this message in context: http://old.nabble.com/Extending-%22choice%22-model-group-in-a-xsd-schema-tp26967149p27141748.html
Sent from the w3.org - xmlschema-devmailing list archive at Nabble.com.
Received on Wednesday, 13 January 2010 09:18:28 GMT
]]>RE: Extending "choice" model group in a xsd schema http://xsd.stylusstudio.com/2010Jan/post06000.htm2010-01-11T09:17:42ZOf course XSD also supports the OO 'composition' pattern, using named model
groups.
Many people prefer this to multiple-inheritance to achieve some of the same
outcomes.
--------------------------------------------------------
Simon Cox
European Commission, Joint Research Centre,
Institute for Environment and Sustainability,
Spatial Data Infrastructures Unit, TP 262
Via E. Fermi, 2749, I-21027 Ispra (VA), Italy
Tel: +39 0332 78 3652
Fax: +39 0332 78 6325
mailto:simon.cox@j...
http://ies.jrc.ec.europa.eu/simon-cox
SDI Unit: http://sdi.jrc.ec.europa.eu/
IES Institute: http://ies.jrc.ec.europa.eu/
JRC: http://www.jrc.ec.europa.eu/
--------------------------------------------------------
-----Original Message-----
From: xmlschema-dev-request@w3.org [mailto:xmlschema-dev-request@w3.org] On
Behalf Of noah_mendelsohn@us.ibm.com
Sent: Friday, 8 January 2010 16:51
To: Michael Kay
Cc: 'Henry S. Thompson'; 'Jaikiran Pai'; xmlschema-dev@w3.org
Subject: RE: Extending "choice" model group in a xsd schema
Michael Kay writes:
> The odd thing though is that the OO languages I'm familiar withtreat
> the fields/methods on a class as a set rather than a sequence, and a
subclass
> can add members to this set; so they don't have any kind of
> user-visible constraint like the one in XSD that says the additions
> have to be at the end of the sequence.
Ah, you youngsters. In C++ it's pretty much a given that methods are mapped
to vtbls in a predictable order, or at least that's my impression.
More to the point, the order of mapping of structure (and thus class) fields
is also significant. Both of these orderings become part of the binary
interface for C++ objects on any given platform, as different compilations
of header files with references to the same classes need to get consistent
vtbl offsets.
Then again, C++ is arguably irrelevant to the XML discussion precisely
because it does support multiple inheritance, with somewhat horrendous
implications for those vtbls under the covers; that multiple inheritance
has no good analog in xsd:extension anyway, as far as I can see. I agree
that most widely deployed scripting languages, as well as Java-class
languages tend to do name-based resolution at runtime, and in that sense
treat the members as sets.
Noah
--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------
"Michael Kay" <mike@saxonica.com>
01/08/2010 10:35 AM
To: <noah_mendelsohn@us.ibm.com>, "'Henry S. Thompson'"
<ht@inf.ed.ac.uk>
cc: "'Jaikiran Pai'" <jai_forums2005@yahoo.co.in>,
<xmlschema-dev@w3.org>
Subject: RE: Extending "choice" model group in a xsd schema
>
> I think there was an intuition on the part of some members of
> the working group that extension would not only be similar in
> spirit to what is done for data inheritance in OO programming
> languages, but that it would facilitate serialization of such
> OO structures to XML.
I thought it was probably something along those lines.
The odd thing though is that the OO languages I'm familiar with treat the
fields/methods on a class as a set rather than a sequence, and a subclass
can add members to this set; so they don't have any kind of user-visible
constraint like the one in XSD that says the additions have to be at the
end
of the sequence.
Regards,
Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay
Received on Monday, 11 January 2010 08:18:43 GMT
]]>Re: Extending "choice" model group in a xsd schema http://xsd.stylusstudio.com/2010Jan/post05000.htm2010-01-08T22:14:32ZOn Fri, Jan 8, 2010 at 9:05 PM, Michael Kay <mike@saxonica.com> wrote:
> The odd thing though is that the OO languages I'm familiar with treat the
> fields/methods on a class as a set rather than a sequence, and a subclass
> can add members to this set; so they don't have any kind of user-visible
> constraint like the one in XSD that says the additions have to be at the end
> of the sequence.
I'm not sure, if comparing unordered fields/methods of a OO class to
say a XSD sequence, is the right thing to do. My experience with OO
languages, convinces me that unordered fields/methods is the right
design for OO languages. Giving order to fields/methods in an OO
program doesn't look right to me (because when the object's consumer
invokes an object's methods, order of methods or says fields, is not
significant -- or to say, is not required from a OO system).
Whereas, ordering (say the element order) is an important requirement
in XML documents.
--
Regards,
Mukul Gandhi
Received on Friday, 8 January 2010 16:52:55 GMT
]]>RE: Extending "choice" model group in a xsd schema http://xsd.stylusstudio.com/2010Jan/post03000.htm2010-01-08T15:35:07Z>
> I think there was an intuition on the part of some members of
> the working group that extension would not only be similar in
> spirit to what is done for data inheritance in OO programming
> languages, but that it would facilitate serialization of such
> OO structures to XML.
I thought it was probably something along those lines.
The odd thing though is that the OO languages I'm familiar with treat the
fields/methods on a class as a set rather than a sequence, and a subclass
can add members to this set; so they don't have any kind of user-visible
constraint like the one in XSD that says the additions have to be at the end
of the sequence.
Regards,
Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay
Received on Friday, 8 January 2010 15:35:43 GMT
]]>Re: Extending "choice" model group in a xsd schema http://xsd.stylusstudio.com/2010Jan/post01000.htm2010-01-08T13:47:50Z-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Michael Kay writes:
> I've never been quite sure whether there is any theoretical justification
> for allowing this kind of extension of a content model and no other kind,
> but that's what the spec does. I assume it's by analogy with object-oriented
> inheritance which allows a subtype to have additional properties that were
> not present in the supertype.
Yes. The parallel with OO design was intentional, with the idea being
that just as many OO implementations handle type derivation in such a
way that a stack frame for an instance of a derived type is the
concatenation of a stack frame for its base type with extra slots for
additional local variable, so in XSD an instance of an extension-derived
type is a concatenation of an instance of the base type with
additional elements as allowed by the derived type.
This is sometimes referred to as the "prefix invariant", in contrast
with the "subsumption invariant" associated with derivation by restriction.
ht
- --
Henry S. Thompson, School of Informatics, University of Edinburgh
Half-time member of W3C Team
10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 651-1426, 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]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFLRzeGkjnJixAXWBoRAvLxAJ9zVj7P1/CSC5V/gwrhNn0TDbGZKgCcCUcR
RxPMZtBSqh3gvagnNhwkFJ0=
=jBxa
-----END PGP SIGNATURE-----
Received on Friday, 8 January 2010 13:48:19 GMT
]]>RE: Extending "choice" model group in a xsd schema http://xsd.stylusstudio.com/2010Jan/post04000.htm2010-01-08T10:50:32ZMichael Kay writes:
> The odd thing though is that the OO languages I'm familiar withtreat the
> fields/methods on a class as a set rather than a sequence, and a
subclass
> can add members to this set; so they don't have any kind of user-visible
> constraint like the one in XSD that says the additions have to
> be at the end
> of the sequence.
Ah, you youngsters. In C++ it's pretty much a given that methods are
mapped to vtbls in a predictable order, or at least that's my impression.
More to the point, the order of mapping of structure (and thus class)
fields is also significant. Both of these orderings become part of the
binary interface for C++ objects on any given platform, as different
compilations of header files with references to the same classes need to
get consistent vtbl offsets.
Then again, C++ is arguably irrelevant to the XML discussion precisely
because it does support multiple inheritance, with somewhat horrendous
implications for those vtbls under the covers; that multiple inheritance
has no good analog in xsd:extension anyway, as far as I can see. I agree
that most widely deployed scripting languages, as well as Java-class
languages tend to do name-based resolution at runtime, and in that sense
treat the members as sets.
Noah
--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------
"Michael Kay" <mike@saxonica.com>
01/08/2010 10:35 AM
To: <noah_mendelsohn@us.ibm.com>, "'Henry S. Thompson'"
<ht@inf.ed.ac.uk>
cc: "'Jaikiran Pai'" <jai_forums2005@yahoo.co.in>,
<xmlschema-dev@w3.org>
Subject: RE: Extending "choice" model group in a xsd schema
>
> I think there was an intuition on the part of some members of
> the working group that extension would not only be similar in
> spirit to what is done for data inheritance in OO programming
> languages, but that it would facilitate serialization of such
> OO structures to XML.
I thought it was probably something along those lines.
The odd thing though is that the OO languages I'm familiar with treat the
fields/methods on a class as a set rather than a sequence, and a subclass
can add members to this set; so they don't have any kind of user-visible
constraint like the one in XSD that says the additions have to be at the
end
of the sequence.
Regards,
Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay
Received on Friday, 8 January 2010 15:51:21 GMT
]]>Re: Extending "choice" model group in a xsd schema http://xsd.stylusstudio.com/2010Jan/post02000.htm2010-01-08T10:20:01ZI think there was an intuition on the part of some members of the working
group that extension would not only be similar in spirit to what is done
for data inheritance in OO programming languages, but that it would
facilitate serialization of such OO structures to XML. I'm not saying I
was entirely convinced of those arguments, in part because there are so
many subtleties in what different languages really do (e.g. multiple
inheritance in C++), but I think it's fair to say that this was a use case
some WG members had in mind.
Noah
--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------
ht@inf.ed.ac.uk (Henry S. Thompson)
Sent by: xmlschema-dev-request@w3.org
01/08/2010 08:47 AM
To: "Michael Kay" <mike@saxonica.com>
cc: "'Jaikiran Pai'" <jai_forums2005@yahoo.co.in>,
<xmlschema-dev@w3.org>, (bcc: Noah Mendelsohn/Cambridge/IBM)
Subject: Re: Extending "choice" model group in a xsd schema
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Michael Kay writes:
> I've never been quite sure whether there is any theoretical
justification
> for allowing this kind of extension of a content model and no other
kind,
> but that's what the spec does. I assume it's by analogy with
object-oriented
> inheritance which allows a subtype to have additional properties that
were
> not present in the supertype.
Yes. The parallel with OO design was intentional, with the idea being
that just as many OO implementations handle type derivation in such a
way that a stack frame for an instance of a derived type is the
concatenation of a stack frame for its base type with extra slots for
additional local variable, so in XSD an instance of an extension-derived
type is a concatenation of an instance of the base type with
additional elements as allowed by the derived type.
This is sometimes referred to as the "prefix invariant", in contrast
with the "subsumption invariant" associated with derivation by
restriction.
ht
- --
Henry S. Thompson, School of Informatics, University of Edinburgh
Half-time member of W3C Team
10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 651-1426, 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]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFLRzeGkjnJixAXWBoRAvLxAJ9zVj7P1/CSC5V/gwrhNn0TDbGZKgCcCUcR
RxPMZtBSqh3gvagnNhwkFJ0=
=jBxa
-----END PGP SIGNATURE-----
Received on Friday, 8 January 2010 15:20:35 GMT
]]>Announce: generateDS.py -- generate bindings http://xsd.stylusstudio.com/2010Jan/post00000.htm2010-01-05T12:02:59ZYou may want to add generateDS.py to the list of tools at
http://www.w3.org/XML/Schema.
I've attached a description below.
Thanks.
- Dave
==================================================================
generateDS.py
===============
generateDS.py generates Python bindings (data structures, class definitions)
from an XML Schema document. These data structures represent the
elements in an XML instance document described by the XML Schema.
generateDS.py also generates parsers (methods in the generated
class) that load an XML document into those data structures, export
methods that can be called to print out the XML instance document
or write it to a file, getter and setter methods, and other
support. In addition, a separate file containing subclasses
(stubs) is optionally generated. The user can add methods to the
subclasses in order to process the contents of an XML document.
For more information, see the documentation at:
http://www.rexx.com/~dkuhlman/generateDS.html.
A distribution package containing generateDS.py, documentation,
and support files is available here:
- http://pypi.python.org/pypi/generateDS/
- http://sourceforge.net/projects/generateds/
==================================================================
--
Dave Kuhlman
http://www.rexx.com/~dkuhlman
Received on Wednesday, 6 January 2010 08:01:48 GMT
]]>Parallel deriving of components and containers using derivation by restriction - consistency problem http://xsd.stylusstudio.com/2009Dec/post01002.htm2009-12-31T03:49:18Z
I have still problems with derivation by restriction (certainly I'm not the
first one).
Problem is concerned with concept of parallel deriving of components and
containers, like described in:
http://www.xfront.com/ElementHierarchy.html
I've tried to isolate the problem to minimal amount of code, which I'm
trying to explain below.
Let's start with elements and types defined in base schema, sys.xsd:
<schema targetNamespace="http://www.org.com/SYS"
xmlns:sys="http://www.org.com/SYS"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<element name="quantity" type="sys:QuantityType"/>
<simpleType name="QuantityType">
<restriction base="integer">
<minInclusive value="0"/>
</restriction>
</simpleType>
<complexType name="BaseType11">
<sequence>
<element ref="sys:quantity"/>
</sequence>
</complexType>
<complexType name="BaseType0u">
<sequence>
<element ref="sys:quantity" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
</complexType>
</schema>
There is simple element "quantity" which is used in two alternative
definitions of complex types: BaseType11 (with default values of minOccurs
and maxOccurs equal to "1") and BaseType0u (with minOccurs="0"
maxOccurs="unbounded").
Now I want to define some derived types in derived schema, app.xsd:
<?xml version="1.0" encoding="UTF-8"?>
<schema
targetNamespace="http://www.org.com/APP"
xmlns:app="http://www.org.com/APP"
xmlns:sys="http://www.org.com/SYS"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<import namespace="http://www.org.com/SYS" schemaLocation="sys.xsd"/>
<element name="restrictedQuantity" type="app:RestrictedQuantityType"
substitutionGroup="sys:quantity"/>
<simpleType name="RestrictedQuantityType">
<restriction base="sys:QuantityType">
<maxInclusive value="10"/>
</restriction>
</simpleType>
<complexType name="DerivedType11VALID">
<complexContent>
<restriction base="sys:BaseType11">
<sequence>
<element ref="app:restrictedQuantity"/>
</sequence>
</restriction>
</complexContent>
</complexType>
<complexType name="DerivedType0uVALID">
<complexContent>
<restriction base="sys:BaseType0u">
<sequence>
<element ref="app:restrictedQuantity"/>
</sequence>
</restriction>
</complexContent>
</complexType>
<complexType name="DerivedType0uINVALID">
<complexContent>
<restriction base="sys:BaseType0u">
<sequence>
<element ref="app:restrictedQuantity" minOccurs="0"
maxOccurs="unbounded"/>
</sequence>
</restriction>
</complexContent>
</complexType>
<complexType name="DerivedType12VALID">
<complexContent>
<restriction base="sys:BaseType0u">
<sequence>
<element ref="sys:quantity" minOccurs="1"
maxOccurs="2"/>
</sequence>
</restriction>
</complexContent>
</complexType>
</schema>
Let's note that element app:restrictedQuantity is in substitution group of
sys:quantity.
Definition of DerivedType11VALID by restricting BaseType11 forcing it to use
app:restrictedQuantity in place of sys:quantity works fine. So far, so good.
Deriving from BaseType0u have some singularities, however.
Definition of DerivedType0uVALID is valid. But it forces two things at once:
using app:restrictedQuantity in place of sys:quantity AND requiring default
minOccurs="1" maxOccurs="1".
When I want to relax this condition (to force app:restrictedQuantity, but to
allow for minOccurs="0" maxOccurs="unbounded" in target schema) it leads to
INVALID definition of DerivedType0uINVALID.
The only thing I can do while restricting occurence count is with definition
of DerivedType12VALID type, where original sys:quantity has to be referred
to make this construction valid.
So it seems that I can restrict element reference (but forcing its usage) OR
restrict usage count (but using original reference). I cannot redefine both.
Worse, when I'm restricting element reference, it is not possible even to
repeat original relaxed usage count.
The error messages are as follows:
Description: rcase-RecurseLax.2: There is not a complete functional mapping
between the particles.
URL: http://www.w3.org/TR/xmlschema-1/#rcase-RecurseLax
Description: derivation-ok-restriction.5.4.2: Error for type
'DerivedType0uINVALID'. The particle of the type is not a valid restriction
of the particle of the base.
URL: http://www.w3.org/TR/xmlschema-1/#derivation-ok-restriction
Maybe it is possible to explain using elaborate definitions from
http://www.w3.org/TR/xmlschema-1, where I am wrong.
But my question tries to be more constructive:
- How can I change my definitions to achieve valid desired effect?
To anticipate fast responses, I've tried another method.
With single sys:quantity element inside BaseType, I can create BaseTypeMod
definition modified as follows:
<complexType name="BaseTypeMod">
<sequence minOccurs="0" maxOccurs="unbounded">
<element ref="sys:quantity"/>
</sequence>
</complexType>
Now I can redefine both element reference and usage count:
<complexType name="DerivedTypeModVALID">
<complexContent>
<restriction base="sys:BaseTypeMod">
<sequence minOccurs="1" maxOccurs="2">
<element ref="app:restrictedQuantity"/>
</sequence>
</restriction>
</complexContent>
</complexType>
Moreover, I can effectively derive even from BaseType0u redefining usage
count but on sequence level, not on element level (seems to be strange that
I can EXTEND sequence usage when deriving by restriction):
<complexType name="DerivedType0uModVALID">
<complexContent>
<restriction base="sys:BaseType0u">
<sequence minOccurs="1" maxOccurs="2">
<element ref="app:restrictedQuantity"/>
</sequence>
</restriction>
</complexContent>
</complexType>
But in real life situations I have more than single element included in
definition of complex type. Each of them may have different requirements
about its usage count and different rules to be used when deriving. So this
construction (placing usage count on sequence level) is of limited usage.
So, my questions still remain:
- Are there any feasible constructions allowing for effective and flexible
derivation by restriction in presented case?
- If not, what is wrong:
- XML schema stiffness and formality?
- my expectations about its usage?
Happy New Year anyway!
--
View this message in context: http://old.nabble.com/Parallel-deriving-of-components-and-containers-using-derivation-by-restriction---consistency-problem-tp26977566p26977566.html
Sent from the w3.org - xmlschema-dev mailing list archive at Nabble.com.
Received on Thursday, 31 December 2009 11:49:48 GMT
]]>RE: Extending "choice" model group in a xsd schema http://xsd.stylusstudio.com/2009Dec/post00002.htm2009-12-30T16:26:20Z
Derivation by extension allows you to create a type that allows the original
content, with new content added at the end. It doesn't allow any other
modification that produces content models which the original type won't
accept.
I've never been quite sure whether there is any theoretical justification
for allowing this kind of extension of a content model and no other kind,
but that's what the spec does. I assume it's by analogy with object-oriented
inheritance which allows a subtype to have additional properties that were
not present in the supertype.
Regards,
Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay
> -----Original Message-----
> From: xmlschema-dev-request@w3.org
> [mailto:xmlschema-dev-request@w3.org] On Behalf Of Jaikiran Pai
> Sent: 28 December 2009 14:29
> To: xmlschema-dev@w3.org
> Subject: Extending "choice" model group in a xsd schema
>
> Hello everyone,
>
> I have been trying to "extend" a type which allows xsd:choice
> model group to add a couple of more allowed choice elements.
> Here's the original xsd:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <xsd:schema xmlns="http://www.w3.org/2001/XMLSchema"
> targetNamespace="http://www.myapp.org/xml/ns/myapp"
> xmlns:myapp="http://www.myapp.org/xml/ns/myapp"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> elementFormDefault="qualified"
> attributeFormDefault="unqualified"
> version="1.0">
>
> <xsd:element name="graphics" type="graphicsType/>
>
> <xsd:complexType name="graphicsType">
> <xsd:sequence>
> <xsd:element name="colours" type="coloursType"/>
> </xsd:sequence>
> </xsd:complexType>
>
>
> <xsd:complexType name="coloursType">
> <xsd:choice maxOccurs="unbounded">
> <xsd:element name="red">
> <xsd:complexType />
> </xsd:elemen>
> <xsd:element name="blue">
> <xsd:complexType />
> </xsd:element>
> </xsd:choice>
> </xsd:complexType>
> </xsd:schema>
>
>
> The extended xsd is as follows:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <xsd:schema xmlns="http://www.w3.org/2001/XMLSchema"
> targetNamespace="http://www.myapp.org/xml/ns/myapp"
> xmlns:myapp="http://www.myapp.org/xml/ns/myapp"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> elementFormDefault="qualified"
> attributeFormDefault="unqualified"
> version="1.0">
>
> <xsd:element name="extended-graphics"
> type="extended-graphicsType/>
>
> <xsd:complexType name="extended-graphicsType">
> <xsd:extension base="graphicsType">
> <xsd:sequence>
> <xsd:element name="brush" type="xsd:string"/>
> </xsd:sequence>
> </xsd:extension>
> </xsd:complexType>
>
> <xsd:complexType name="more-coloursType" >
> <xsd:extension base="coloursType">
> <xsd:choice maxOccurs="unbounded">
> <xsd:element name="dark-red">
> <xsd:complexType />
> </xsd:elemen>
> <xsd:element name="dark-blue">
> <xsd:complexType />
> </xsd:element>
> </xsd:choice>
> </xsd:extension>
> </xsd:complexType>
>
> </xsd:schema>
>
> So here i have a "coloursType" with a choice of "red" and
> "blue" and the extended "more-coloursType" has the additional
> "dark-red" and "dark-blue". Then in my xml i am trying to do this:
>
> <extended-graphics xmlns="http://www.myapp.org/xml/ns/myapp"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xmlns:myapp="http://www.myapp.org/xml/ns/myapp">
>
> <colours xsi:type="more-coloursType">
> <dark-red/>
> </colour>
>
> </extended-graphics>
>
>
> So in the xml, i am trying to use the extended
> "more-coloursType" and specifying a "dark-red" value. But
> this fails validation, with a message saying that "dark-red"
> is not allowed in this place. It starts working if i first
> have a normal colour (either red or blue) and then have dark-red:
>
> <colours xsi:type="more-coloursType">
> <blue/>
> <dark-red/>
> </colour>
>
> My understanding was with this kind of extension, with the
> "choice" elements i would have something like:
>
> (red | blue)* (dark-red | dark-blue)*
>
> but this doesn't seem to be the case. Am i missing something?
> Are there any changes that i'll have to make to my xsd to allow:
>
> <colours xsi:type="more-coloursType">
> <dark-red/>
> </colour>
>
> regards,
> -Jaikiran
>
>
>
> The INTERNET now has a personality. YOURS! See your
> Yahoo! Homepage. http://in.yahoo.com/
> --0-1910538151-1262010512=0684
> Content-Type: text/html; charset=o-8859-1
> Content-Transfer-Encoding: quoted-printable
>
> <table cellspacing="0" cellpadding="0" border="0" ><tr><td
> valign="top" style="font: inherit;">Hello everyone,<br><br>I
> have been trying to "extend" a type which allows xsd:choice
> model group to add a couple of more allowed choice elements.
> Here's the original xsd:<br><br><?xml version="1.0"
> encoding="UTF-8"?><br><xsd:schema
> xmlns="http://www.w3.org/2001/XMLSchema"<br>
>
> targetNamespace="http://www.myapp.org/xml/ns/myapp"<br> &
> nbsp;
> xmlns:myapp="http://www.myapp.org/xml/ns/myapp"<br>  
> ;
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"<br> &n
> bsp;
> elementFormDefault="qualified"<br> &nbs
> p;
>
> attributeFormDefault="unqualified"<br>
>
> version="1.0"><br><br> <xsd:element
> name="graphics" type="graphicsType/><br><br>
> <xsd:complexType
> name="graphicsType"><br>
> <xsd:sequence><br>
> <xsd:element name="colours"
> type="coloursType"/><br>
> </xsd:sequence><br>
> </xsd:complexType><br>
> <br><br> <xsd:complexType
> name="coloursType"><br>
> <xsd:choice
> maxOccurs="unbounded"><br>
> <xsd:element
> name="red"><br>
> <xsd:complexType
> /><br>
> </xsd:elemen><br>
> <xsd:element name="blue"><br>
>
> <xsd:complexType /><br>
>
> </xsd:element>
> <br>
> </xsd:choice><br>
> </xsd:complexType>
> <br></xsd:schema><br><br><br>The extended xsd is
> as follows: <br><br><?xml version="1.0"
> encoding="UTF-8"?><br><xsd:schema
> xmlns="http://www.w3.org/2001/XMLSchema"<br>
>
> targetNamespace="http://www.myapp.org/xml/ns/myapp"<br> &
> nbsp;
> xmlns:myapp="http://www.myapp.org/xml/ns/myapp"<br>  
> ;
>
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"<br> &n
> bsp;
> elementFormDefault="qualified"<br> &nbs
> p;
> attributeFormDefault="unqualified"<br>
>
> version="1.0"><br><br> <xsd:element
> name="extended-graphics"
> type="extended-graphicsType/><br>
> <br> <xsd:complexType
> name="extended-graphicsType"><br>
> <xsd:extension
> base="graphicsType"><br>
> <xsd:sequence><br>
>
> <xsd:element name="brush"
> type="xsd:string"/><br>
>
> </xsd:sequence><br>
>
> </xsd:extension><br>
> </xsd:complexType><br><br>
> <xsd:complexType name="more-coloursType"
> ><br>
> <xsd:extension
> base="coloursType"><br>
> <xsd:choice
> maxOccurs="unbounded"><br>
>
> <xsd:element
> name="dark-red"><br>
>
> <xsd:complexType /><br>
>
> </xsd:elemen><br>
> <xsd:element
> name="dark-blue"><br>
>
> <xsd:complexType /><br>
>
> </xsd:element>
> <br>
> </xsd:choice><br>
>
> </xsd:extension><br>
> </xsd:complexType><br>
> <br></xsd:schema><br><br>So
> here i have a "coloursType" with a choice of "red" and "blue"
> and the extended "more-coloursType" has the additional
> "dark-red" and "dark-blue". Then in my xml i am trying to do
> this:<br><br><extended-graphics
> xmlns="http://www.myapp.org/xml/ns/myapp"<br>  
> ;
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"<br> 
> ; &
> nbsp;
> xmlns:myapp="http://www.myapp.org/xml/ns/myapp"><br><br>&nb
> sp;
> <colours
> xsi:type="more-coloursType"><br>
> <dark-red/><br>
> </colour>  
> ;
> <br> &nbs
> p;
> <br></extended-graphics>
> <br> <br><br>So in the xml, i am trying to use the
> extended "more-coloursType" and specifying a "dark-red"
> value. But this fails validation, with a message saying that
> "dark-red" is not allowed in this place. It starts working if
> i first have a normal colour (either red or blue) and then
> have dark-red: <br><br><colours
> xsi:type="more-coloursType"><br>
> <blue/><br>
> <dark-red/><br>
> </colour> <br><br>My understanding
> was with this kind of extension, with the "choice" elements
> i would have something like: <br><br>(red | blue)* (dark-red
> | dark-blue)*<br><br>but this doesn't seem to be the case. Am
> i missing something? Are there any changes that i'll have to
> make to my xsd to allow: <br><br>
> <colours xsi:type="more-coloursType"><br>
> <dark-red/><br>
> </colour>
> <br><br>regards,<br>-Jaikiran<br></td></tr></table><br>
>
>
>
> <!--1--><hr size=1></hr>
> The INTERNET now has a personality. YOURS! <a
> href="http://in.rd.yahoo.com/tagline_yyi_1/*http://in.yahoo.co
> m/" target="_blank">See your Yahoo! Homepage</a>.
> --0-1910538151-1262010512=0684--
>
>
Received on Wednesday, 30 December 2009 16:26:49 GMT
]]>Re: Extending "choice" model group in a xsd schema http://xsd.stylusstudio.com/2009Dec/post09001.htm2009-12-30T10:18:59ZOn 12/28/2009 9:28 AM, Jaikiran Pai wrote:
> (red | blue)* (dark-red | dark-blue)*
What you actually have is:
(red | blue)+ (dark-red | dark-blue)+
Your choice groups don't have minOccurs=0.
If you are after (red | blue | dark-red | dark-blue)+, you aren't going
to achieve it the way you are going. Walmsley suggests using
substitution groups to extend choice groups (see 19.5.2 Extensions for
Choice Groups, in Definitive XML Schema). You might take a look at that
approach and see if it meets your needs.
--
Kevin Braun
Objective Systems, Inc.
REAL WORLD ASN.1 AND XML SOLUTIONS
Tel: +1 (484) 875-9841
Fax: +1 (484) 875-9830
Toll-free: (877) 307-6855 (USA only)
http://www.obj-sys.com
Received on Wednesday, 30 December 2009 15:21:50 GMT
]]>Extending "choice" model group in a xsd schema http://xsd.stylusstudio.com/2009Dec/post08001.htm2009-12-28T19:58:32Z
Received on Wednesday, 30 December 2009 12:52:42 GMT
]]>Re: [RESEND] Derivation by restriction http://xsd.stylusstudio.com/2009Dec/post06001.htm2009-12-11T14:03:51ZThis discussion was a long time ago:
http://lists.w3.org/Archives/Public/xmlschema-dev/2002Mar/0219.html
but it seems that I've reached the same problem.
Opposite to Roger L. Costello statement, Best Practices from xFront
*advises* parallel substitution group element hierarchies in elements and
element containers as well. See "Implementing Substitution Group Element
Hierarchies" in:
http://www.xfront.com/ElementHierarchy.html
I've seen in "OpenGISR Geography Markup Language (GML) Encoding Standard"
version 3.2.1 opened possibility for this, e.g. in 21.4.2.2 "User-defined
geometry property types" we have:
"A geometry property type may be a restriction of gml:GeometryPropertyType,
but this is not a requirement."
My question is - why it is not a practice in GML 3.2.1?:
In GML, we have AbstractGeometry element:
<element name="AbstractGeometry" type="gml:AbstractGeometryType"
abstract="true" substitutionGroup="gml:AbstractGML"/>
and "generic" Property type (container) like below:
<complexType name="GeometryPropertyType">
<sequence minOccurs="0">
<element ref="gml:AbstractGeometry"/>
</sequence>
<attributeGroup ref="gml:AssociationAttributeGroup"/>
<attributeGroup ref="gml:OwnershipAttributeGroup"/>
</complexType>
Then there are *lot of* concrete geometry types, extending
AbstractGeometryType, and associated geometry elements, belonging to
substitutionGroup of AbstractGeometry. e.g. Point (indirect derivation and
obsolete content simplified for brevity):
<complexType name="PointType">
<complexContent>
<extension base="gml:AbstractGeometryType">
<sequence>
<element ref="gml:pos"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="Point" type="gml:PointType"
substitutionGroup="gml:AbstractGeometry"/>
All these Point, Curve, Surface, ..., PointArray, CurveArray, SurfaceArray,
... have their own Property (container) types defined but not within any
hierarchy, only "following the same pattern", like below:
<complexType name="PointPropertyType">
<sequence minOccurs="0">
<element ref="gml:Point"/>
</sequence>
<attributeGroup ref="gml:AssociationAttributeGroup"/>
<attributeGroup ref="gml:OwnershipAttributeGroup"/>
</complexType>
My question is: What's wrong with defining all similar containers using
"infamous" derivation by restriction, like below:
<complexType name="PointPropertyType">
<complexContent>
<restriction base="gml:GeometryPropertyType">
<sequence>
<element ref="gml:Point"/>
</sequence>
</restriction>
</complexContent>
</complexType>
Is it only due to troubles with MSXML validation (see
http://markmail.org/message/fotntmddcmmwhkoc) ?
Element gml:Point is in substitution group of gml:AbstractGeometry, so can
be used here, isn't it? Ot it is the problem that PointType is EXTENSION of
AbstractGeometryType, while I suggest to define PointPropertyType as
RESTRICTION of GeometryPropertyType? Best Practices paper cited above
doesn't mention about this.
With my suggestion, at least two benefits can be seen:
- after changing or extending usage of attributeGroup's
(gml:AssociationAttributeGroup, gml:OwnershipAttributeGroup) it wouldn't be
necessary to "follow the same pattern" in all duplicated container
definitions;
- it would be possible to define some flexible content models allowing
Feature to have *any* geometryProperty, replaceable by concrete
pointProperty, curveProperty and so on;
This flexibility would be specifically convenient when creating layered
schemas - flexible generic one with "templated", and concretized specific
ones with restricted content.
Please explain me where I'm wrong.
Received on Friday, 11 December 2009 13:04:35 GMT
]]>RE: [RESEND] Derivation by restriction http://xsd.stylusstudio.com/2009Dec/post07001.htm2009-12-11T09:13:00Z
[
I've seen in "OpenGISR Geography Markup Language (GML) EncodingStandard"
version 3.2.1 opened possibility for this, e.g. in 21.4.2.2
"User-defined
geometry property types" we have:
"A geometry property type may be a restriction of
gml:GeometryPropertyType,
but this is not a requirement."
My question is - why it is not a practice in GML 3.2.1?:
]
My understanding is that this is intended to say that in comparison with
the encouraged GML object type hierarchy, the property type hierarchy is
not necessary in GML, and it may be avoided to prevent from the
complicated issues in schema validation as you suggested, and
difficulties in instance processing caused by the
derivation-by-restriction as there is no compatible concept in either
conventional OO programming languages or relational database theory.
Lisa
-----Original Message-----
From: xmlschema-dev-request@w3.org [mailto:xmlschema-dev-request@w3.org]
On Behalf Of Krzysztof Fink-Finowicki
Sent: Friday, December 11, 2009 5:04 AM
To: xmlschema-dev@w3.org
Subject: Re: [RESEND] Derivation by restriction
This discussion was a long time ago:
http://lists.w3.org/Archives/Public/xmlschema-dev/2002Mar/0219.html
but it seems that I've reached the same problem.
Opposite to Roger L. Costello statement, Best Practices from xFront
*advises* parallel substitution group element hierarchies in elements
and
element containers as well. See "Implementing Substitution Group Element
Hierarchies" in:
http://www.xfront.com/ElementHierarchy.html
I've seen in "OpenGISR Geography Markup Language (GML) Encoding
Standard"
version 3.2.1 opened possibility for this, e.g. in 21.4.2.2
"User-defined
geometry property types" we have:
"A geometry property type may be a restriction of
gml:GeometryPropertyType,
but this is not a requirement."
My question is - why it is not a practice in GML 3.2.1?:
In GML, we have AbstractGeometry element:
<element name="AbstractGeometry" type="gml:AbstractGeometryType"
abstract="true" substitutionGroup="gml:AbstractGML"/>
and "generic" Property type (container) like below:
<complexType name="GeometryPropertyType">
<sequence minOccurs="0">
<element ref="gml:AbstractGeometry"/>
</sequence>
<attributeGroup ref="gml:AssociationAttributeGroup"/>
<attributeGroup ref="gml:OwnershipAttributeGroup"/>
</complexType>
Then there are *lot of* concrete geometry types, extending
AbstractGeometryType, and associated geometry elements, belonging to
substitutionGroup of AbstractGeometry. e.g. Point (indirect derivation
and
obsolete content simplified for brevity):
<complexType name="PointType">
<complexContent>
<extension base="gml:AbstractGeometryType">
<sequence>
<element ref="gml:pos"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="Point" type="gml:PointType"
substitutionGroup="gml:AbstractGeometry"/>
All these Point, Curve, Surface, ..., PointArray, CurveArray,
SurfaceArray,
... have their own Property (container) types defined but not within any
hierarchy, only "following the same pattern", like below:
<complexType name="PointPropertyType">
<sequence minOccurs="0">
<element ref="gml:Point"/>
</sequence>
<attributeGroup ref="gml:AssociationAttributeGroup"/>
<attributeGroup ref="gml:OwnershipAttributeGroup"/>
</complexType>
My question is: What's wrong with defining all similar containers using
"infamous" derivation by restriction, like below:
<complexType name="PointPropertyType">
<complexContent>
<restriction base="gml:GeometryPropertyType">
<sequence>
<element ref="gml:Point"/>
</sequence>
</restriction>
</complexContent>
</complexType>
Is it only due to troubles with MSXML validation (see
http://markmail.org/message/fotntmddcmmwhkoc) ?
Element gml:Point is in substitution group of gml:AbstractGeometry, so
can
be used here, isn't it? Ot it is the problem that PointType is EXTENSION
of
AbstractGeometryType, while I suggest to define PointPropertyType as
RESTRICTION of GeometryPropertyType? Best Practices paper cited above
doesn't mention about this.
With my suggestion, at least two benefits can be seen:
- after changing or extending usage of attributeGroup's
(gml:AssociationAttributeGroup, gml:OwnershipAttributeGroup) it wouldn't
be
necessary to "follow the same pattern" in all duplicated container
definitions;
- it would be possible to define some flexible content models allowing
Feature to have *any* geometryProperty, replaceable by concrete
pointProperty, curveProperty and so on;
This flexibility would be specifically convenient when creating layered
schemas - flexible generic one with "templated", and concretized
specific
ones with restricted content.
Please explain me where I'm wrong.
Received on Friday, 11 December 2009 17:13:52 GMT
]]>Re: Why xsi:type works only inwards, not outwards? http://xsd.stylusstudio.com/2009Dec/post03001.htm2009-12-03T15:45:29Z
On 12/3/2009 3:08 PM, Krzysztof FF wrote:
> Kevin Braun wrote:
>
>> Hi,
>>
>> One brief comment embedded below.
>>
>> Kevin
>>
>> On 12/3/2009 11:13 AM, Krzysztof FF wrote:
>>
>>> Hi all,
>>>
>>>
>> [...]
>>
>>> BUT USING xsi:type on both levels is illegal:
>>>
>>> <sys:Entity xsi:type="RoomType">
>>> <!-- namespaces omitted for brevity -->
>>> <sys:category xsi:type="RoomCategoryType">living</sys:category>
>>> </sys:Entity1>
>>>
>>>
>>>
>> I believe this would be invalid because you have indicated that
>> sys:Entity is actually a "RoomType", but then you give a sys:category
>> for the child, which is not legal according to "RoomType" - you need an
>> "app:roomCategory" element. Once you tell it the type the element
>> should be validated against, you have to follow the model for that type.
>>
>>
>
> But I told that sys:category is actually RoomCategoryType using xsi:type, so
> why id doesn't works? Why actual type is not exposed, only plain one?
>
When you told it the type for sys:Entity was RoomType, you were telling
it you are going to provide data that would validate against RoomType.
In other words, you are essentially saying "don't accept a sys:category
element, be more restrictive and demand an app:roomCategory element".
Yes, you specified "RoomCategoryType" for the sys:category element, but
RoomType doesn't allow just *any* element of RoomCategoryType, it
requires an app:roomCategory element (or an element in its substitution
group). The definition of RoomType specifies not only the type of
elements that should appear, but also the names for those elements.
I hope that helps.
-Kevin
Received on Thursday, 3 December 2009 20:48:09 GMT
]]>Re: Why xsi:type works only inwards, not outwards? http://xsd.stylusstudio.com/2009Dec/post01001.htm2009-12-03T14:00:20ZHi,
One brief comment embedded below.
Kevin
On 12/3/2009 11:13 AM, Krzysztof FF wrote:
> Hi all,
>
> I'm trying to define two-level layered schema - one with generic "system"
> model, second with specific "application" model.
>
> When trying to expose application data using generic system model elements
> specified by using xsi:type attribute referring to application model types,
> I've encountered some asymetry in treating it while validating data.
>
> My example is somehow simplified so as to reflect the issue from topic.
>
> Let's start with system schema, sys.xsd:
>
> <schema
> targetNamespace="http://www.org.com/SYS"
> xmlns:sys="http://www.org.com/SYS"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> xmlns="http://www.w3.org/2001/XMLSchema"
> elementFormDefault="qualified">
>
> <element name="Entity" type="sys:EntityType"/>
> <complexType name="EntityType">
> <sequence minOccurs="0" maxOccurs="unbounded">
> <element ref="sys:category"/>
> </sequence>
> </complexType>
>
> <element name="category" type="sys:CategoryType"/>
> <simpleType name="CategoryType">
> <restriction base="string"/>
> </simpleType>
>
> </schema>
>
> Now I want to define specific rules for Room derived from Entity by
> restriction in app.xsd:
>
> <schema
> targetNamespace="http://www.org.com/APP"
> xmlns:app="http://www.org.com/APP"
> xmlns:sys="http://www.org.com/SYS"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> xmlns="http://www.w3.org/2001/XMLSchema"
> elementFormDefault="qualified">
>
> <import
> namespace="http://www.org.com/SYS"
> schemaLocation="sys.xsd"/>
>
> <element name="Room" type="app:RoomType" substitutionGroup="sys:Entity"
> />
> <complexType name="RoomType">
> <complexContent>
> <restriction base="sys:EntityType">
> <sequence>
> <element ref="app:roomCategory"></element>
> </sequence>
> </restriction>
> </complexContent>
> </complexType>
>
> <element name="roomCategory" type="app:RoomCategoryType"
> substitutionGroup="sys:category"/>
> <simpleType name="RoomCategoryType">
> <restriction base="sys:CategoryType">
> <enumeration value="living"></enumeration>
> <enumeration value="bedroom"></enumeration>
> <enumeration value="kitchen"></enumeration>
> </restriction>
> </simpleType>
>
> </schema>
>
> Now I can write data using application model:
>
> <Room>
> <!-- namespaces omitted for brevity -->
> <roomCategory>living</roomCategory>
> </Room>
>
> I could write the same data using plain system model, because Room is
> derived from Entity by restriction:
>
> <sys:Entity>
> <!-- namespaces omitted for brevity -->
> <sys:category>living</sys:category>
> </sys:Entity1>
>
> The reason for flattening data to system model is to make it understandable
> for some low-level processing, whatever it is (i.e. without exact knowledge
> on application specifics).
>
> But there are some drawbacks:
> - validation can be made only against system schema, not application schema;
> - information about actual application types has been stripped out, although
> it could be of later use for some high-level processing, whatever it is
> (i.e. using knowledge of aplication specifics).
>
> My natural attempt was to use xsi:type attribute.
>
> But it occured that I can write
>
> <sys:Entity xsi:type="RoomType">
> <!-- namespaces omitted for brevity -->
> <roomCategory>living</roomCategory>
> </sys:Entity1>
>
> OR
>
> <sys:Entity>
> <!-- namespaces omitted for brevity -->
> <sys:category xsi:type=RoomCategoryType">living</sys:category>
> </sys:Entity>
>
> BUT USING xsi:type on both levels is illegal:
>
> <sys:Entity xsi:type="RoomType">
> <!-- namespaces omitted for brevity -->
> <sys:category xsi:type=RoomCategoryType">living</sys:category>
> </sys:Entity1>
>
>
I believe this would be invalid because you have indicated that
sys:Entity is actually a "RoomType", but then you give a sys:category
for the child, which is not legal according to "RoomType" - you need an
"app:roomCategory" element. Once you tell it the type the element
should be validated against, you have to follow the model for that type.
> It seems that xsi:type "works" inwards, forcing inner content of element to
> be validated along referred type. But in the same time, it does not work
> outwards, i.e. inner element is not exposed as referred type - element name
> is interpreted explicitly instead.
>
> This is what I assume some drawback in how XML schema works, and causes my
> concept for exposing data using layered schemas to be illegal.
>
> I wonder if somebody could explain if there are some valid reasons for
> hiding xsi:type attribute referred from inner elements to their parent
> elements.
>
>
>
>
Kevin Braun
--
Objective Systems, Inc.
REAL WORLD ASN.1 AND XML SOLUTIONS
Tel: +1 (484) 875-9841
Fax: +1 (484) 875-9830
Toll-free: (877) 307-6855 (USA only)
http://www.obj-sys.com
Received on Thursday, 3 December 2009 19:03:05 GMT
]]>Re: Why xsi:type works only inwards, not outwards? http://xsd.stylusstudio.com/2009Dec/post04001.htm2009-12-03T13:18:46Z
Kevin Braun wrote:
>
>
> When you told it the type for sys:Entity was RoomType, you were telling
> it you are going to provide data that would validate against RoomType.
> In other words, you are essentially saying "don't accept a sys:category
> element, be more restrictive and demand an app:roomCategory element".
> Yes, you specified "RoomCategoryType" for the sys:category element, but
> RoomType doesn't allow just *any* element of RoomCategoryType, it
> requires an app:roomCategory element (or an element in its substitution
> group). The definition of RoomType specifies not only the type of
> elements that should appear, but also the names for those elements.
>
> I hope that helps.
>
> -Kevin
>
>
Yes, indeed. Now I understand.
It was probably my wishful thinking that threw me in conviction that my
concept *should* work.
Thank you for clear clarification.
Krzysztof
--
View this message in context: http://old.nabble.com/Why-xsi%3Atype-works-only-inwards%2C-not-outwards--tp26628621p26633339.html
Sent from the w3.org - xmlschema-devmailing list archive at Nabble.com.
Received on Thursday, 3 December 2009 21:19:15 GMT
]]>Re: Why xsi:type works only inwards, not outwards? http://xsd.stylusstudio.com/2009Dec/post02001.htm2009-12-03T12:08:55Z
Kevin Braun wrote:
>
> Hi,
>
> One brief comment embedded below.
>
> Kevin
>
> On 12/3/2009 11:13 AM, Krzysztof FF wrote:
>> Hi all,
>>
> [...]
>>
>> BUT USING xsi:type on both levels is illegal:
>>
>> <sys:Entity xsi:type="RoomType">
>> <!-- namespaces omitted for brevity -->
>> <sys:category xsi:type="RoomCategoryType">living</sys:category>
>> </sys:Entity1>
>>
>>
> I believe this would be invalid because you have indicated that
> sys:Entity is actually a "RoomType", but then you give a sys:category
> for the child, which is not legal according to "RoomType" - you need an
> "app:roomCategory" element. Once you tell it the type the element
> should be validated against, you have to follow the model for that type.
>
But I told that sys:category is actually RoomCategoryType using xsi:type, so
why id doesn't works? Why actual type is not exposed, only plain one?
It seems I have to live with that, but it doesn't suits me.
Thank you anyway.
--
View this message in context: http://old.nabble.com/Why-xsi%3Atype-works-only-inwards%2C-not-outwards--tp26628621p26632358.html
Sent from the w3.org - xmlschema-devmailing list archive at Nabble.com.
Received on Thursday, 3 December 2009 20:09:30 GMT
]]>Why xsi:type works only inwards, not outwards? http://xsd.stylusstudio.com/2009Dec/post00001.htm2009-12-03T08:13:30ZHi all,
I'm trying to define two-level layered schema - one with generic "system"
model, second with specific "application" model.
When trying to expose application data using generic system model elements
specified by using xsi:type attribute referring to application model types,
I've encountered some asymetry in treating it while validating data.
My example is somehow simplified so as to reflect the issue from topic.
Let's start with system schema, sys.xsd:
<schema
targetNamespace="http://www.org.com/SYS"
xmlns:sys="http://www.org.com/SYS"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<element name="Entity" type="sys:EntityType"/>
<complexType name="EntityType">
<sequence minOccurs="0" maxOccurs="unbounded">
<element ref="sys:category"/>
</sequence>
</complexType>
<element name="category" type="sys:CategoryType"/>
<simpleType name="CategoryType">
<restriction base="string"/>
</simpleType>
</schema>
Now I want to define specific rules for Room derived from Entity by
restriction in app.xsd:
<schema
targetNamespace="http://www.org.com/APP"
xmlns:app="http://www.org.com/APP"
xmlns:sys="http://www.org.com/SYS"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified">
<import
namespace="http://www.org.com/SYS"
schemaLocation="sys.xsd"/>
<element name="Room" type="app:RoomType" substitutionGroup="sys:Entity"
/>
<complexType name="RoomType">
<complexContent>
<restriction base="sys:EntityType">
<sequence>
<element ref="app:roomCategory"></element>
</sequence>
</restriction>
</complexContent>
</complexType>
<element name="roomCategory" type="app:RoomCategoryType"
substitutionGroup="sys:category"/>
<simpleType name="RoomCategoryType">
<restriction base="sys:CategoryType">
<enumeration value="living"></enumeration>
<enumeration value="bedroom"></enumeration>
<enumeration value="kitchen"></enumeration>
</restriction>
</simpleType>
</schema>
Now I can write data using application model:
<Room>
<!-- namespaces omitted for brevity -->
<roomCategory>living</roomCategory>
</Room>
I could write the same data using plain system model, because Room is
derived from Entity by restriction:
<sys:Entity>
<!-- namespaces omitted for brevity -->
<sys:category>living</sys:category>
</sys:Entity1>
The reason for flattening data to system model is to make it understandable
for some low-level processing, whatever it is (i.e. without exact knowledge
on application specifics).
But there are some drawbacks:
- validation can be made only against system schema, not application schema;
- information about actual application types has been stripped out, although
it could be of later use for some high-level processing, whatever it is
(i.e. using knowledge of aplication specifics).
My natural attempt was to use xsi:type attribute.
But it occured that I can write
<sys:Entity xsi:type="RoomType">
<!-- namespaces omitted for brevity -->
<roomCategory>living</roomCategory>
</sys:Entity1>
OR
<sys:Entity>
<!-- namespaces omitted for brevity -->
<sys:category xsi:type=RoomCategoryType">living</sys:category>
</sys:Entity>
BUT USING xsi:type on both levels is illegal:
<sys:Entity xsi:type="RoomType">
<!-- namespaces omitted for brevity -->
<sys:category xsi:type=RoomCategoryType">living</sys:category>
</sys:Entity1>
It seems that xsi:type "works" inwards, forcing inner content of element to
be validated along referred type. But in the same time, it does not work
outwards, i.e. inner element is not exposed as referred type - element name
is interpreted explicitly instead.
This is what I assume some drawback in how XML schema works, and causes my
concept for exposing data using layered schemas to be illegal.
I wonder if somebody could explain if there are some valid reasons for
hiding xsi:type attribute referred from inner elements to their parent
elements.
--
View this message in context: http://old.nabble.com/Why-xsi%3Atype-works-only-inwards%2C-not-outwards--tp26628621p26628621.html
Sent from the w3.org - xmlschema-dev mailing list archive at Nabble.com.
Received on Thursday, 3 December 2009 18:30:11 GMT
]]>RE: Extending Types http://xsd.stylusstudio.com/2009Dec/post09000.htm2009-12-02T12:55:56ZFWIW, sounds like a use case for typed wildcards [1] if they existed.
<xs:complexType name="MyMessageType">
<xs:sequence>
<xs:element name="Header">
<xs:complexType>
<xs:sequence>
<xs:element name="Who" type="xs:string"></xs:element>
<xs:element name="When" type="xs:string"></xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:any type="BaseBusinessContent"/>
</xs:sequence>
</xs:complexType>
<xs:complexType name="BaseBusinessContent">
<xs:sequence>
<xs:element name="Code" type="xs:string"></xs:element>
<xs:element name="Description" type="xs:string"></xs:element>
</xs:sequence>
</xs:complexType>
xan
[1] http://www.w3.org/Bugs/Public/show_bug.cgi?id=2866
-----Original Message-----
From: xmlschema-dev-request@w3.org [mailto:xmlschema-dev-request@w3.org] On Behalf Of Flavio Cordova
Sent: Tuesday, December 01, 2009 4:25 PM
To: xmlschema-dev@w3.org
Subject: Re: Extending Types
I may have found another way, although is not exactly what I'm looking for..
In definition.xsd
<xs:complexType name="MyMessageType">
<xs:sequence>
<xs:element name="Header">
<xs:complexType>
<xs:sequence>
<xs:element name="Who" type="xs:string"></xs:element>
<xs:element name="When" type="xs:string"></xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element ref="AbstractBusinessContent"></xs:element>
</xs:sequence>
</xs:complexType>
<xs:element name="AbstractBusinessContent" abstract="true"></xs:element>
<xs:element name="MyMsg" type="MyMessage"></xs:element>
Notice that I have create a reference element of MyMessage
(ref="AbstractBusinessContent") and defined this element as abstract
(although, "abstract" seems to be useless, it avoids that the user
could use this element in the XML).
Then in child.xsd:
<xs:include schemaLocation="definition.xsd"></xs:include>
<xs:complexType name="BusinessContent">
<xs:sequence>
<xs:element name="Code" type="xs:string"></xs:element>
<xs:element name="Description" type="xs:string"></xs:element>
</xs:sequence>
</xs:complexType>
<xs:element name="BusinessContent" type="BusinessContent"
substitutionGroup="AbstractBusinessContent"></xs:element>
Notice here that I just defined another complexType (BusinessContent)
and created an element using substituitionGroup. That means I could
use it instead of AbstractBusinessContent.
Why it's not perfect: Now I can't pre-define any content for BusinessContent...
I'm feeling much more comfortable, yet not satisfied... I mean, I can
solve my problem just setting GenericInformation a sibling of
BusinessContent, but I still think there should be a way to make
abstract types do the job.. :(
On Tue, Dec 1, 2009 at 5:27 PM, Flavio Cordova <flavio.cordova@gmail.com> wrote:
> You mean something like this ?
>
> <xs:complexType name="AbstractBusinessContentType"> <!-- No abstract
> attribute anymore -->
> <xs:sequence>
> <xs:group ref="BusinessContentGroup"></xs:group>
> </xs:sequence>
> </xs:complexType>
>
> Then I leave definition.xsd with no definition for
> BusinessContentGroup and only define it in item.xsd, changing
> xs:redefine to xs:include, right ?
> That works but then the parent XSD becomes invalid, since the group
> isn't defined there, right ?
>
> I'm not comfortable with this solution (although I will use it if
> nothing betters comes up :D).. Is there any other ?
> I know it could sound a little picky, but I seems to me abstract
> should do the work and I'm just forgetting something...
>
>
>
>
> On Tue, Dec 1, 2009 at 5:00 PM, Michael Kay <mike@saxonica.com> wrote:
>>>
>>> Actually, in my case, I need to create a complexType that
>>> will be extended by other people, just overwriting (or
>>> "implementing") the BusinessContent tag.
>>
>> I think the simplest solution is a low-tech one: have your type refer to a
>> named model group called BusinessContentGroup which you define in a separate
>> schema document, which people can edit.
>>
>> OK that has disadvantages, for example it makes it difficult for different
>> extensions of the schema to coexist, but those disadvantages apply to nearly
>> all other techniques as well.
>>
>> Regards,
>>
>> Michael Kay
>> http://www.saxonica.com/
>> http://twitter.com/michaelhkay
>>
>>
>
Received on Wednesday, 2 December 2009 17:56:44 GMT
]]>Re: Extending Types http://xsd.stylusstudio.com/2009Dec/post08000.htm2009-12-01T19:25:26ZI may have found another way, although is not exactly what I'm looking for..
In definition.xsd
<xs:complexType name="MyMessageType">
<xs:sequence>
<xs:element name="Header">
<xs:complexType>
<xs:sequence>
<xs:element name="Who" type="xs:string"></xs:element>
<xs:element name="When" type="xs:string"></xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element ref="AbstractBusinessContent"></xs:element>
</xs:sequence>
</xs:complexType>
<xs:element name="AbstractBusinessContent" abstract="true"></xs:element>
<xs:element name="MyMsg" type="MyMessage"></xs:element>
Notice that I have create a reference element of MyMessage
(ref="AbstractBusinessContent") and defined this element as abstract
(although, "abstract" seems to be useless, it avoids that the user
could use this element in the XML).
Then in child.xsd:
<xs:include schemaLocation="definition.xsd"></xs:include>
<xs:complexType name="BusinessContent">
<xs:sequence>
<xs:element name="Code" type="xs:string"></xs:element>
<xs:element name="Description" type="xs:string"></xs:element>
</xs:sequence>
</xs:complexType>
<xs:element name="BusinessContent" type="BusinessContent"
substitutionGroup="AbstractBusinessContent"></xs:element>
Notice here that I just defined another complexType (BusinessContent)
and created an element using substituitionGroup. That means I could
use it instead of AbstractBusinessContent.
Why it's not perfect: Now I can't pre-define any content for BusinessContent...
I'm feeling much more comfortable, yet not satisfied... I mean, I can
solve my problem just setting GenericInformation a sibling of
BusinessContent, but I still think there should be a way to make
abstract types do the job.. :(
On Tue, Dec 1, 2009 at 5:27 PM, Flavio Cordova <flavio.cordova@gmail.com> wrote:
> You mean something like this ?
>
> <xs:complexType name="AbstractBusinessContentType"> <!-- No abstract
> attribute anymore -->
> <xs:sequence>
> <xs:group ref="BusinessContentGroup"></xs:group>
> </xs:sequence>
> </xs:complexType>
>
> Then I leave definition.xsd with no definition for
> BusinessContentGroup and only define it in item.xsd, changing
> xs:redefine to xs:include, right ?
> That works but then the parent XSD becomes invalid, since the group
> isn't defined there, right ?
>
> I'm not comfortable with this solution (although I will use it if
> nothing betters comes up :D).. Is there any other ?
> I know it could sound a little picky, but I seems to me abstract
> should do the work and I'm just forgetting something...
>
>
>
>
> On Tue, Dec 1, 2009 at 5:00 PM, Michael Kay <mike@saxonica.com> wrote:
>>>
>>> Actually, in my case, I need to create a complexType that
>>> will be extended by other people, just overwriting (or
>>> "implementing") the BusinessContent tag.
>>
>> I think the simplest solution is a low-tech one: have your type refer to a
>> named model group called BusinessContentGroup which you define in a separate
>> schema document, which people can edit.
>>
>> OK that has disadvantages, for example it makes it difficult for different
>> extensions of the schema to coexist, but those disadvantages apply to nearly
>> all other techniques as well.
>>
>> Regards,
>>
>> Michael Kay
>> http://www.saxonica.com/
>> http://twitter.com/michaelhkay
>>
>>
>
Received on Tuesday, 1 December 2009 21:26:00 GMT
]]>RE: Extending Types http://xsd.stylusstudio.com/2009Dec/post06000.htm2009-12-01T19:00:48Z>
> Actually, in my case, I need to create a complexType that
> will be extended by other people, just overwriting (or
> "implementing") the BusinessContent tag.
I think the simplest solution is a low-tech one: have your type refer to a
named model group called BusinessContentGroup which you define in a separate
schema document, which people can edit.
OK that has disadvantages, for example it makes it difficult for different
extensions of the schema to coexist, but those disadvantages apply to nearly
all other techniques as well.
Regards,
Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay
Received on Tuesday, 1 December 2009 19:01:17 GMT
]]>RE: Extending Types http://xsd.stylusstudio.com/2009Dec/post04000.htm2009-12-01T18:20:02ZYour reply was off-list, I'm copying it back to the list.
The problem I think is that when you extend a type, the extension always
goes at the end.
Regards,
Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay
> -----Original Message-----
> From: Flavio Cordova [mailto:flavio.cordova@gmail.com]
> Sent: 01 December 2009 18:01
> To: Michael Kay
> Subject: Re: Extending Types
>
> Well.. I have changed some things but that's how it looks like now:
>
> In definition.xsd
>
> DEFINITION:
> <xs:complexType name="AbstractBusinessContentType"
> abstract="true">
> <xs:sequence>
> <xs:element name="CustomInformation">
> ....
> </xs:element>
> </xs:sequence>
> </xs:complexType>
>
> ELEMENT:
> <xs:element name="BusinessContent"
> type="AbstractBusinessContentType"></xs:element>
>
>
> in item.xsd, I have this:
>
> <xs:redefine schemaLocation="../definition.xsd">
> <xs:complexType name="AbstractBusinessContentType">
> <xs:complexContent>
> <xs:extension
> base="AbstractBusinessContentType">
> <xs:sequence>
> <xs:element
> name="Code" type="xs:string"></xs:element>
> <xs:element
> name="Description" type="xs:string"></xs:element>
> </xs:sequence>
> </xs:extension>
> </xs:complexContent>
> </xs:complexType>
> </xs:redefine>
>
> But it doesn't work too.. When I create the XML the validator
> shows that Code is not a valid child for BusinessContent.
>
> <BusinessContent>
> <Code>UN</Code> <!-- ### Invalid child ### -->
> <Description>Unidade</Description>
> <CustomInformation>
> <Table name="labInfo">
> <Record>
> <Field name="quanticMass">120</Field>
> <Field
> name="fusionMethod">Nuclear</Field>
> </Record>
> </Table>
> </CustomInformation>
> </BusinessContent>
>
> Talking about compositions or inheritance, I don't know
> exactly how it would work (I mean, I know the concepts, but I
> really don't what it would do with my xml.. :D)
>
> I'll try to find something about named model groups to see if
> I could use them...
>
>
> On Tue, Dec 1, 2009 at 12:00 PM, Michael Kay
> <mike@saxonica.com> wrote:
> >> I have an XML that looks like this:
> >>
> >> <MyMessage>
> >> <HeaderInfo>
> >> ....
> >> </HeaderInfo>
> >> <BusinessContent>
> >> #someSpecificInformation# <!-- This will be defined in
> a "child"
> >> XSD
> >> <GenericInfo>
> >> <information>a</information>
> >> </GenericInfo>
> >> </BusinessContent>
> >> </MyMessage>
> >>
> >> In a file called definition.xsd, I defined the whole structure,
> >> including the BusinessContent ComplexType.. Then, I
> defined another
> >> XSD, called item.xsd, where I'd like to define only the content of
> >> the BusinessContent, so I did something like this:
> >>
> >> <xs:include schemaLocation="definition.xsd"></xs:include>
> >> <xs:complexType name="BusinessContentTypeImpl">
> >> <xs:complexContent>
> >> <xs:extension base="GenericBusinessContentType">
> >> <xs:sequence>
> >> <xs:element name="Code" type="xs:string"></xs:element>
> >> <xs:element name="Description"
> type="xs:string"></xs:element>
> >> </xs:sequence>
> >> </xs:extension>
> >> </xs:complexContent>
> >> </xs:complexType>
> >
> > What does the element declaration for BusinessContent look
> like? Is it
> > using the GenericBusinessContentType or
> BusinessContentTypeImpl? You
> > can only use the BusinessContentTypeImpl content model if
> the type is
> > declared as BusinessContentTypeImpl either in the element
> declaration,
> > or in an xsi:type attribute in the instance.
> >
> > Have you considered using named model groups instead? As with any
> > object-oriented design, people sometimes overlook that
> composition is
> > more powerful than inheritance.
> >
> > Regards,
> >
> > Michael Kay
> > http://www.saxonica.com/
> > http://twitter.com/michaelhkay
> >
> >
> >>
> >> When I create an XML (adding tags Code and Description), I get an
> >> error because tags Code and Description are not valid children for
> >> BusinessContent, although I've extended it...
> >>
> >> I'd also like to force extension of BusinessContent. Then
> I tried to
> >> use the abstract attribute, but then I couldn't add the
> <GenericInfo>
> >> child...
> >>
> >> So, my questions are:
> >> 1) how should I extend BusinessContent
> >> (GenericBusinessContentType) so I could keep the current elements
> >> (GenericInfo) add more elements..
> >> 2) how could I force a "child" xsd file to import the
> definitions.xsd
> >> and extend BusinessContent.
> >>
> >> Thanks !
> >>
> >>
> >
> >
Received on Tuesday, 1 December 2009 18:20:34 GMT
]]>Re: Extending Types http://xsd.stylusstudio.com/2009Dec/post07000.htm2009-12-01T17:27:16ZYou mean something like this ?
<xs:complexType name="AbstractBusinessContentType"> <!-- No abstract
attribute anymore -->
<xs:sequence>
<xs:group ref="BusinessContentGroup"></xs:group>
</xs:sequence>
</xs:complexType>
Then I leave definition.xsd with no definition for
BusinessContentGroup and only define it in item.xsd, changing
xs:redefine to xs:include, right ?
That works but then the parent XSD becomes invalid, since the group
isn't defined there, right ?
I'm not comfortable with this solution (although I will use it if
nothing betters comes up :D).. Is there any other ?
I know it could sound a little picky, but I seems to me abstract
should do the work and I'm just forgetting something...
On Tue, Dec 1, 2009 at 5:00 PM, Michael Kay <mike@saxonica.com> wrote:
>>
>> Actually, in my case, I need to create a complexType that
>> will be extended by other people, just overwriting (or
>> "implementing") the BusinessContent tag.
>
> I think the simplest solution is a low-tech one: have your type refer to a
> named model group called BusinessContentGroup which you define in a separate
> schema document, which people can edit.
>
> OK that has disadvantages, for example it makes it difficult for different
> extensions of the schema to coexist, but those disadvantages apply to nearly
> all other techniques as well.
>
> Regards,
>
> Michael Kay
> http://www.saxonica.com/
> http://twitter.com/michaelhkay
>
>
Received on Tuesday, 1 December 2009 19:27:57 GMT
]]>Fwd: Extending Types http://xsd.stylusstudio.com/2009Dec/post05000.htm2009-12-01T16:21:01ZI'm considering this (http://www.w3schools.com/Schema/el_group.asp) as
a source for named groups.. :-)
In this case, I understand that in the "child" xsd file I would
compound a new complexType using parts already defined in
definitions.xsd, right ?
Actually, in my case, I need to create a complexType that will be
extended by other people, just overwriting (or "implementing") the
BusinessContent tag. I don't want people have to care about how to
assemble parts to create a correct message.. I just want them to focus
on the specialized part...
However, I have some freedom to change the structure... for example, I
could move the CustomInformation out of BusinessContent, if it could
make things easier.. but I think keeping it would be more
challenging.. :)
Am I too high ? :)
---------- Forwarded message ----------
From: Flavio Cordova <flavio.cordova@gmail.com>
Date: Tue, Dec 1, 2009 at 4:00 PM
Subject: Re: Extending Types
To: Michael Kay <mike@saxonica.com>
Well.. I have changed some things but that's how it looks like now:
In definition.xsd
DEFINITION:
<xs:complexType name="AbstractBusinessContentType" abstract="true">
<xs:sequence>
<xs:element name="CustomInformation">
....
</xs:element>
</xs:sequence>
</xs:complexType>
ELEMENT:
<xs:element name="BusinessContent"
type="AbstractBusinessContentType"></xs:element>
in item.xsd, I have this:
<xs:redefine schemaLocation="../definition.xsd">
<xs:complexType name="AbstractBusinessContentType">
<xs:complexContent>
<xs:extension base="AbstractBusinessContentType">
<xs:sequence>
<xs:element name="Code"
type="xs:string"></xs:element>
<xs:element
name="Description" type="xs:string"></xs:element>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:redefine>
But it doesn't work too.. When I create the XML the validator shows
that Code is not a valid child for BusinessContent.
<BusinessContent>
<Code>UN</Code> <!-- ### Invalid child ### -->
<Description>Unidade</Description>
<CustomInformation>
<Table name="labInfo">
<Record>
<Field name="quanticMass">120</Field>
<Field name="fusionMethod">Nuclear</Field>
</Record>
</Table>
</CustomInformation>
</BusinessContent>
Talking about compositions or inheritance, I don't know exactly how it
would work (I mean, I know the concepts, but I really don't what it
would do with my xml.. :D)
I'll try to find something about named model groups to see if I could
use them...
On Tue, Dec 1, 2009 at 12:00 PM, Michael Kay <mike@saxonica.com> wrote:
>> I have an XML that looks like this:
>>
>> <MyMessage>
>> <HeaderInfo>
>> ....
>> </HeaderInfo>
>> <BusinessContent>
>> #someSpecificInformation# <!-- This will be defined in a
>> "child" XSD
>> <GenericInfo>
>> <information>a</information>
>> </GenericInfo>
>> </BusinessContent>
>> </MyMessage>
>>
>> In a file called definition.xsd, I defined the whole
>> structure, including the BusinessContent ComplexType.. Then,
>> I defined another XSD, called item.xsd, where I'd like to
>> define only the content of the BusinessContent, so I did
>> something like this:
>>
>> <xs:include schemaLocation="definition.xsd"></xs:include>
>> <xs:complexType name="BusinessContentTypeImpl">
>> <xs:complexContent>
>> <xs:extension base="GenericBusinessContentType">
>> <xs:sequence>
>> <xs:element name="Code" type="xs:string"></xs:element>
>> <xs:element name="Description" type="xs:string"></xs:element>
>> </xs:sequence>
>> </xs:extension>
>> </xs:complexContent>
>> </xs:complexType>
>
> What does the element declaration for BusinessContent look like? Is it using
> the GenericBusinessContentType or BusinessContentTypeImpl? You can only use
> the BusinessContentTypeImpl content model if the type is declared as
> BusinessContentTypeImpl either in the element declaration, or in an xsi:type
> attribute in the instance.
>
> Have you considered using named model groups instead? As with any
> object-oriented design, people sometimes overlook that composition is more
> powerful than inheritance.
>
> Regards,
>
> Michael Kay
> http://www.saxonica.com/
> http://twitter.com/michaelhkay
>
>
>>
>> When I create an XML (adding tags Code and Description), I
>> get an error because tags Code and Description are not valid
>> children for BusinessContent, although I've extended it...
>>
>> I'd also like to force extension of BusinessContent. Then I
>> tried to use the abstract attribute, but then I couldn't add
>> the <GenericInfo> child...
>>
>> So, my questions are:
>> 1) how should I extend BusinessContent
>> (GenericBusinessContentType) so I could keep the current
>> elements (GenericInfo) add more elements..
>> 2) how could I force a "child" xsd file to import the
>> definitions.xsd and extend BusinessContent.
>>
>> Thanks !
>>
>>
>
>
Received on Tuesday, 1 December 2009 18:21:40 GMT
]]>Fwd: Extending Types http://xsd.stylusstudio.com/2009Dec/post03000.htm2009-12-01T16:09:43ZSorry.. I didn't send to the list.. :(
---------- Forwarded message ----------
From: Flavio Cordova <flavio.cordova@gmail.com>
Date: Tue, Dec 1, 2009 at 4:00 PM
Subject: Re: Extending Types
To: Michael Kay <mike@saxonica.com>
Well.. I have changed some things but that's how it looks like now:
In definition.xsd
DEFINITION:
<xs:complexType name="AbstractBusinessContentType" abstract="true">
<xs:sequence>
<xs:element name="CustomInformation">
....
</xs:element>
</xs:sequence>
</xs:complexType>
ELEMENT:
<xs:element name="BusinessContent"
type="AbstractBusinessContentType"></xs:element>
in item.xsd, I have this:
<xs:redefine schemaLocation="../definition.xsd">
<xs:complexType name="AbstractBusinessContentType">
<xs:complexContent>
<xs:extension base="AbstractBusinessContentType">
<xs:sequence>
<xs:element name="Code"
type="xs:string"></xs:element>
<xs:element
name="Description" type="xs:string"></xs:element>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:redefine>
But it doesn't work too.. When I create the XML the validator shows
that Code is not a valid child for BusinessContent.
<BusinessContent>
<Code>UN</Code> <!-- ### Invalid child ### -->
<Description>Unidade</Description>
<CustomInformation>
<Table name="labInfo">
<Record>
<Field name="quanticMass">120</Field>
<Field name="fusionMethod">Nuclear</Field>
</Record>
</Table>
</CustomInformation>
</BusinessContent>
Talking about compositions or inheritance, I don't know exactly how it
would work (I mean, I know the concepts, but I really don't what it
would do with my xml.. :D)
I'll try to find something about named model groups to see if I could
use them...
On Tue, Dec 1, 2009 at 12:00 PM, Michael Kay <mike@saxonica.com> wrote:
>> I have an XML that looks like this:
>>
>> <MyMessage>
>> <HeaderInfo>
>> ....
>> </HeaderInfo>
>> <BusinessContent>
>> #someSpecificInformation# <!-- This will be defined in a
>> "child" XSD
>> <GenericInfo>
>> <information>a</information>
>> </GenericInfo>
>> </BusinessContent>
>> </MyMessage>
>>
>> In a file called definition.xsd, I defined the whole
>> structure, including the BusinessContent ComplexType.. Then,
>> I defined another XSD, called item.xsd, where I'd like to
>> define only the content of the BusinessContent, so I did
>> something like this:
>>
>> <xs:include schemaLocation="definition.xsd"></xs:include>
>> <xs:complexType name="BusinessContentTypeImpl">
>> <xs:complexContent>
>> <xs:extension base="GenericBusinessContentType">
>> <xs:sequence>
>> <xs:element name="Code" type="xs:string"></xs:element>
>> <xs:element name="Description" type="xs:string"></xs:element>
>> </xs:sequence>
>> </xs:extension>
>> </xs:complexContent>
>> </xs:complexType>
>
> What does the element declaration for BusinessContent look like? Is it using
> the GenericBusinessContentType or BusinessContentTypeImpl? You can only use
> the BusinessContentTypeImpl content model if the type is declared as
> BusinessContentTypeImpl either in the element declaration, or in an xsi:type
> attribute in the instance.
>
> Have you considered using named model groups instead? As with any
> object-oriented design, people sometimes overlook that composition is more
> powerful than inheritance.
>
> Regards,
>
> Michael Kay
> http://www.saxonica.com/
> http://twitter.com/michaelhkay
>
>
>>
>> When I create an XML (adding tags Code and Description), I
>> get an error because tags Code and Description are not valid
>> children for BusinessContent, although I've extended it...
>>
>> I'd also like to force extension of BusinessContent. Then I
>> tried to use the abstract attribute, but then I couldn't add
>> the <GenericInfo> child...
>>
>> So, my questions are:
>> 1) how should I extend BusinessContent
>> (GenericBusinessContentType) so I could keep the current
>> elements (GenericInfo) add more elements..
>> 2) how could I force a "child" xsd file to import the
>> definitions.xsd and extend BusinessContent.
>>
>> Thanks !
>>
>>
>
>
Received on Tuesday, 1 December 2009 18:10:23 GMT
]]>RE: Extending Types http://xsd.stylusstudio.com/2009Dec/post02000.htm2009-12-01T14:00:42Z> I have an XML that looks like this:
>
> <MyMessage>
> <HeaderInfo>
> ....
> </HeaderInfo>
> <BusinessContent>
> #someSpecificInformation# <!-- This will be defined in a
> "child" XSD
> <GenericInfo>
> <information>a</information>
> </GenericInfo>
> </BusinessContent>
> </MyMessage>
>
> In a file called definition.xsd, I defined the whole
> structure, including the BusinessContent ComplexType.. Then,
> I defined another XSD, called item.xsd, where I'd like to
> define only the content of the BusinessContent, so I did
> something like this:
>
> <xs:include schemaLocation="definition.xsd"></xs:include>
> <xs:complexType name="BusinessContentTypeImpl">
> <xs:complexContent>
> <xs:extension base="GenericBusinessContentType">
> <xs:sequence>
> <xs:element name="Code" type="xs:string"></xs:element>
> <xs:element name="Description" type="xs:string"></xs:element>
> </xs:sequence>
> </xs:extension>
> </xs:complexContent>
> </xs:complexType>
What does the element declaration for BusinessContent look like? Is it using
the GenericBusinessContentType or BusinessContentTypeImpl? You can only use
the BusinessContentTypeImpl content model if the type is declared as
BusinessContentTypeImpl either in the element declaration, or in an xsi:type
attribute in the instance.
Have you considered using named model groups instead? As with any
object-oriented design, people sometimes overlook that composition is more
powerful than inheritance.
Regards,
Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay
>
> When I create an XML (adding tags Code and Description), I
> get an error because tags Code and Description are not valid
> children for BusinessContent, although I've extended it...
>
> I'd also like to force extension of BusinessContent. Then I
> tried to use the abstract attribute, but then I couldn't add
> the <GenericInfo> child...
>
> So, my questions are:
> 1) how should I extend BusinessContent
> (GenericBusinessContentType) so I could keep the current
> elements (GenericInfo) add more elements..
> 2) how could I force a "child" xsd file to import the
> definitions.xsd and extend BusinessContent.
>
> Thanks !
>
>
Received on Tuesday, 1 December 2009 14:01:17 GMT
]]>Extending Types http://xsd.stylusstudio.com/2009Dec/post01000.htm2009-12-01T10:34:19ZHello People...
I'm not being able to work with extended types and after some hours
trying to find a solution, I decided to ask for help.. :)
here's the problem..
I have an XML that looks like this:
<MyMessage>
<HeaderInfo>
....
</HeaderInfo>
<BusinessContent>
#someSpecificInformation# <!-- This will be defined in a "child" XSD
<GenericInfo>
<information>a</information>
</GenericInfo>
</BusinessContent>
</MyMessage>
In a file called definition.xsd, I defined the whole structure,
including the BusinessContent ComplexType.. Then, I defined another
XSD, called item.xsd, where I'd like to define only the content of the
BusinessContent, so I did something like this:
<xs:include schemaLocation="definition.xsd"></xs:include>
<xs:complexType name="BusinessContentTypeImpl">
<xs:complexContent>
<xs:extension base="GenericBusinessContentType">
<xs:sequence>
<xs:element name="Code" type="xs:string"></xs:element>
<xs:element name="Description" type="xs:string"></xs:element>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
When I create an XML (adding tags Code and Description), I get an
error because tags Code and Description are not valid children for
BusinessContent, although I've extended it...
I'd also like to force extension of BusinessContent. Then I tried to
use the abstract attribute, but then I couldn't add the <GenericInfo>
child...
So, my questions are:
1) how should I extend BusinessContent (GenericBusinessContentType) so
I could keep the current elements (GenericInfo) add more elements..
2) how could I force a "child" xsd file to import the definitions.xsd
and extend BusinessContent.
Thanks !
Received on Tuesday, 1 December 2009 13:46:21 GMT
]]>RE: Reg. <all> model group extension http://xsd.stylusstudio.com/2009Dec/post00000.htm2009-12-01T09:57:42ZHi Michel Kay,
Thank you very much for your reply.
Thanks and Regards,
Bharath.
-----Original Message-----
From: xmlschema-dev-request@w3.org [mailto:xmlschema-dev-request@w3.org] On
Behalf Of Michael Kay
Sent: Monday, November 30, 2009 10:06 PM
To: 'bharath'; 'Pete Cordell'; xmlschema-dev@w3.org
Cc: rajithr@huawei.com; arathikarki@huawei.com; ksrilakshmi@huawei.com
Subject: RE: Reg. <all> model group extension
Well, the schema spec is not easy to read: it needs a lot of study to
understand the language it uses. And indeed, it seems my explanation in my
previous email was wrong! Let's take this rule:
[Definition:] For a particle (call it E, for extension) to be a valid
extension of another particle (call it B, for base) one of the following
must be true:
1 They are the same particle.
2 E's {min occurs}={max occurs}=1 and its {term} is a sequence group whose
{particles}' first member is a particle all of whose properties,
recursively, are identical to those of B, with the exception of {annotation}
properties.
First you need to understand what a particle is. Loosely, it's anything that
appears in a content model but in practice we're only concerned here with
group-level particles (not leaf particles, which are either element
particles or wildcards). A group-level particle is technically referred to
as a "model group", and it has a term which is either a choice group, a
sequence group, or an all group.
The theory here is that we build the schema components (such as particles)
from the source XSD, and then test whether the components we have built are
valid. (In practice, the processor will usually do these tests while
building the components, and may not even have the capability to build
invalid components). So we first have to see what the rules are for
constructing a complex type component by extension. These are given under
Complex Type Definition with complex content Schema Component in section
3.4.2. Look for the rules for the {content type} property. For both your
complex types, rule 2.2 applies, which means that the effective content is
the particle corresponding to the <all> element; and then rule 3.2.3
applies, which means that the {content type} of the derived type is
effectively the model group:
<sequence>
<all>
<element name="a1" type="string"/>
<element name="a2" type="string"/>
</all>
<all>
<element name="a3" type="string"/>
</all>
</sequence>
Now there's a rule in 3.8.6, "Schema Component Constraint: All Group
Limited", which determines whether this model group is actually valid, and
it turns out that it isn't.
The rule says:
When a model group has {compositor} all, then all of the following must be
true:
1 It appears only as the value of one or both of the following properties:
1.1 the {model group} property of a model group definition.
1.2 the {term} property of a particle with {max occurs}=1 which is part of a
pair which constitutes the {content type} of a complex type definition.
2 The {max occurs} of all the particles in the {particles} of the group must
be 0 or 1.
Now here we have two model groups with compositor "all" that appear as part
of a model group with compositor "sequence", which doesn't satisfy either
1.1 or 1.2 (the sequence is not a "model group definition", you only get a
"model group definition" from a <group> element in the schema document.). So
this extended model group isn't valid and therefore the schema isn't valid.
I mentioned the rule Schema Component Constraint: Particle Valid (Extension)
but actually we don't get this far. If we did get this far, the rule would
test whether
<sequence>
<all>
<element name="a1" type="string"/>
<element name="a2" type="string"/>
</all>
<all>
<element name="a3" type="string"/>
</all>
</sequence>
was a valid extension of
<all>
<element name="a1" type="string"/>
<element name="a2" type="string"/> </all>
and as it happens, if it got past the rule at 3.8.6, then it would be.
Regards,
Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay
Received on Tuesday, 1 December 2009 04:28:29 GMT
]]>RE: Reg. <all> model group extension http://xsd.stylusstudio.com/2009Nov/post08001.htm2009-11-30T21:26:39Z
Hi Michek Kay,
Can you please give me any example for the clause 2 of 3.9.6 as i have not
understood that point clearly.
Thanks and Regards,
Bharath.
-----Original Message-----
From: xmlschema-dev-request@w3.org [mailto:xmlschema-dev-request@w3.org] On
Behalf Of Michael Kay
Sent: Monday, November 30, 2009 9:12 PM
To: 'bharath'; 'Pete Cordell'; xmlschema-dev@w3.org
Cc: rajithr@huawei.com; arathikarki@huawei.com; ksrilakshmi@huawei.com
Subject: RE: Reg. <all> model group extension
Look for Schema Component Constraint: Particle Valid (Extension) in 3.9.6.
Clause 2 says that the {term} must be a sequence group (it cannot be choice
or all).
Regards,
Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay
> -----Original Message-----
> From: xmlschema-dev-request@w3.org
> [mailto:xmlschema-dev-request@w3.org] On Behalf Of bharath
> Sent: 30 November 2009 15:23
> To: 'Michael Kay'; 'Pete Cordell'; xmlschema-dev@w3.org
> Cc: rajithr@huawei.com; arathikarki@huawei.com; ksrilakshmi@huawei.com
> Subject: RE: Reg. <all> model group extension
>
> Hi Pete Cordell/ Michek Kay
>
> Thanks for your reply.
> Can you please tell me where I can find this limitation of <all>
> extension in xml schema specification.
>
>
> Thanks and Regards,
> Bharath.
>
>
> -----Original Message-----
> From: xmlschema-dev-request@w3.org
> [mailto:xmlschema-dev-request@w3.org] On Behalf Of Michael Kay
> Sent: Monday, November 30, 2009 8:41 PM
> To: 'Pete Cordell'; 'bharath'; xmlschema-dev@w3.org
> Cc: rajithr@huawei.com; arathikarki@huawei.com
> Subject: RE: Reg. <all> model group extension
>
>
> >
> > I don't believe you are allowed to extend xs:all in XSD 1.0.
> > This has been relaxed in the upcoming 1.1.
>
> Correct (thanks for spotting this, Pete).
>
> After fixing a couple of typos (bad XML end tags), I get the following
> from Saxon 9.2 running with -xsdversion:1.0:
>
> Error on line 15 of test.xsd:
> The type DerivedType is defined with xs:all so (in XSD 1.0) it
> cannot be derived by
> extension from a non-empty type
> Schema processing failed: The schema is invalid
>
> but with -xsdversion:1.1 I get:
>
> Schema checking successful.
>
> Regards,
>
> Michael Kay
> http://www.saxonica.com/
> http://twitter.com/michaelhkay
>
>
>
Received on Monday, 30 November 2009 15:57:28 GMT
]]>RE: Reg. <all> model group extension http://xsd.stylusstudio.com/2009Nov/post06001.htm2009-11-30T20:52:49ZHi Pete Cordell/ Michek Kay
Thanks for your reply.
Can you please tell me where I can find this limitation of <all> extension
in xml schema specification.
Thanks and Regards,
Bharath.
-----Original Message-----
From: xmlschema-dev-request@w3.org [mailto:xmlschema-dev-request@w3.org] On
Behalf Of Michael Kay
Sent: Monday, November 30, 2009 8:41 PM
To: 'Pete Cordell'; 'bharath'; xmlschema-dev@w3.org
Cc: rajithr@huawei.com; arathikarki@huawei.com
Subject: RE: Reg. <all> model group extension
>
> I don't believe you are allowed to extend xs:all in XSD 1.0.
> This has been relaxed in the upcoming 1.1.
Correct (thanks for spotting this, Pete).
After fixing a couple of typos (bad XML end tags), I get the following from
Saxon 9.2 running with -xsdversion:1.0:
Error on line 15 of test.xsd:
The type DerivedType is defined with xs:all so (in XSD 1.0) it cannot be
derived by
extension from a non-empty type
Schema processing failed: The schema is invalid
but with -xsdversion:1.1 I get:
Schema checking successful.
Regards,
Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay
Received on Monday, 30 November 2009 15:23:58 GMT
]]>RE: Reg. <all> model group extension http://xsd.stylusstudio.com/2009Nov/post03001.htm2009-11-30T19:56:03ZHi..
I am getting error in libxml2 as well as altova spy saying that
"An all modelgroup is neither allowed in complexType definition
"tns:BaseType" nor in its extension tns: DerivedType". "
Can you please lookinto this schema whether it is valid or not.
Thanks and Regards,
Bharath.
htipl
HUAWEI TECHNOLOGIES CO.,LTD. huawei_logo
<file:///C:/Documents%20and%20Settings/b72392/Application%20Data/Microsoft/S
ignatures/outlook_huawei_logo_en.jpg>
Address: Huawei Industrial Base
Bantian Longgang
Shenzhen 518129, P.R.China
www.huawei.com
----------------------------------------------------------------------------
---------------------------------------------------------
This e-mail and its attachments contain confidential information from
HUAWEI, which
is intended only for the person or entity whose address is listed above. Any
use of the
information contained herein in any way (including, but not limited to,
total or partial
disclosure, reproduction, or dissemination) by persons other than the
intended
recipient(s) is prohibited. If you receive this e-mail in error, please
notify the sender by
phone or email immediately and delete it!
_____
From: Michael Kay [mailto:mike@saxonica.com]
Sent: Monday, November 30, 2009 7:36 PM
To: 'bharath'; xmlschema-dev@w3.org
Cc: rajithr@huawei.com; arathikarki@huawei.com
Subject: RE: Reg. <all> model group extension
It looks OK to me by visual inspection - I haven't tried running it.
Why do you doubt that it's OK?
Regards,
Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay
_____
From: xmlschema-dev-request@w3.org [mailto:xmlschema-dev-request@w3.org] On
Behalf Of bharath
Sent: 30 November 2009 13:55
To: xmlschema-dev@w3.org
Cc: rajithr@huawei.com; arathikarki@huawei.com
Subject: Reg. <all> model group extension
Hi All,
I have one doubt reg. <all> model group extension.
i have the following schema.
<schema targetNamespace="testschema" xmlns:tns="testschema">
<complexType name="BaseType">
<all>
<element name="a1" type="string"/>
<element name="a2" type="string"/>
</all>
</complexType>
<complexType name="DerivedType">
<complexContent>
<extension base="tns:BaseType">
<all>
<element name="a3" type="string"/>
</all>
<extension>
</complexContent>
<complexType>
</schema>
Is this extension of the <all> model group correct??
If not please provide me the reason. Please reply me as soon as possible.
Thanks and Regards,
Bharath.
Received on Monday, 30 November 2009 14:26:49 GMT
]]>Reg. <all> model group extension http://xsd.stylusstudio.com/2009Nov/post01001.htm2009-11-30T19:25:20ZHi All,
I have one doubt reg. <all> model group extension.
i have the following schema.
<schema targetNamespace="testschema" xmlns:tns="testschema">
<complexType name="BaseType">
<all>
<element name="a1" type="string"/>
<element name="a2" type="string"/>
</all>
</complexType>
<complexType name="DerivedType">
<complexContent>
<extension base="tns:BaseType">
<all>
<element name="a3" type="string"/>
</all>
<extension>
</complexContent>
<complexType>
</schema>
Is this extension of the <all> model group correct??
If not please provide me the reason. Please reply me as soon as possible.
Thanks and Regards,
Bharath.
Received on Monday, 30 November 2009 13:56:10 GMT
]]>RE: Reg. <all> model group extension http://xsd.stylusstudio.com/2009Nov/post09001.htm2009-11-30T16:35:38ZWell, the schema spec is not easy to read: it needs a lot of study to
understand the language it uses. And indeed, it seems my explanation in my
previous email was wrong! Let's take this rule:
[Definition:] For a particle (call it E, for extension) to be a valid
extension of another particle (call it B, for base) one of the following
must be true:
1 They are the same particle.
2 E's {min occurs}={max occurs}=1 and its {term} is a sequence group whose
{particles}' first member is a particle all of whose properties,
recursively, are identical to those of B, with the exception of {annotation}
properties.
First you need to understand what a particle is. Loosely, it's anything that
appears in a content model but in practice we're only concerned here with
group-level particles (not leaf particles, which are either element
particles or wildcards). A group-level particle is technically referred to
as a "model group", and it has a term which is either a choice group, a
sequence group, or an all group.
The theory here is that we build the schema components (such as particles)
from the source XSD, and then test whether the components we have built are
valid. (In practice, the processor will usually do these tests while
building the components, and may not even have the capability to build
invalid components). So we first have to see what the rules are for
constructing a complex type component by extension. These are given under
Complex Type Definition with complex content Schema Component in section
3.4.2. Look for the rules for the {content type} property. For both your
complex types, rule 2.2 applies, which means that the effective content is
the particle corresponding to the <all> element; and then rule 3.2.3
applies, which means that the {content type} of the derived type is
effectively the model group:
<sequence>
<all>
<element name="a1" type="string"/>
<element name="a2" type="string"/>
</all>
<all>
<element name="a3" type="string"/>
</all>
</sequence>
Now there's a rule in 3.8.6, "Schema Component Constraint: All Group
Limited", which determines whether this model group is actually valid, and
it turns out that it isn't.
The rule says:
When a model group has {compositor} all, then all of the following must be
true:
1 It appears only as the value of one or both of the following properties:
1.1 the {model group} property of a model group definition.
1.2 the {term} property of a particle with {max occurs}=1 which is part of a
pair which constitutes the {content type} of a complex type definition.
2 The {max occurs} of all the particles in the {particles} of the group must
be 0 or 1.
Now here we have two model groups with compositor "all" that appear as part
of a model group with compositor "sequence", which doesn't satisfy either
1.1 or 1.2 (the sequence is not a "model group definition", you only get a
"model group definition" from a <group> element in the schema document.). So
this extended model group isn't valid and therefore the schema isn't valid.
I mentioned the rule Schema Component Constraint: Particle Valid (Extension)
but actually we don't get this far. If we did get this far, the rule would
test whether
<sequence>
<all>
<element name="a1" type="string"/>
<element name="a2" type="string"/>
</all>
<all>
<element name="a3" type="string"/>
</all>
</sequence>
was a valid extension of
<all>
<element name="a1" type="string"/>
<element name="a2" type="string"/>
</all>
and as it happens, if it got past the rule at 3.8.6, then it would be.
Regards,
Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay
Received on Monday, 30 November 2009 16:36:12 GMT
]]>RE: Reg. <all> model group extension http://xsd.stylusstudio.com/2009Nov/post07001.htm2009-11-30T15:41:32ZLook for Schema Component Constraint: Particle Valid (Extension) in 3.9.6.
Clause 2 says that the {term} must be a sequence group (it cannot be choice
or all).
Regards,
Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay
> -----Original Message-----
> From: xmlschema-dev-request@w3.org
> [mailto:xmlschema-dev-request@w3.org] On Behalf Of bharath
> Sent: 30 November 2009 15:23
> To: 'Michael Kay'; 'Pete Cordell'; xmlschema-dev@w3.org
> Cc: rajithr@huawei.com; arathikarki@huawei.com; ksrilakshmi@huawei.com
> Subject: RE: Reg. <all> model group extension
>
> Hi Pete Cordell/ Michek Kay
>
> Thanks for your reply.
> Can you please tell me where I can find this limitation of
> <all> extension in xml schema specification.
>
>
> Thanks and Regards,
> Bharath.
>
>
> -----Original Message-----
> From: xmlschema-dev-request@w3.org
> [mailto:xmlschema-dev-request@w3.org] On Behalf Of Michael Kay
> Sent: Monday, November 30, 2009 8:41 PM
> To: 'Pete Cordell'; 'bharath'; xmlschema-dev@w3.org
> Cc: rajithr@huawei.com; arathikarki@huawei.com
> Subject: RE: Reg. <all> model group extension
>
>
> >
> > I don't believe you are allowed to extend xs:all in XSD 1.0.
> > This has been relaxed in the upcoming 1.1.
>
> Correct (thanks for spotting this, Pete).
>
> After fixing a couple of typos (bad XML end tags), I get the
> following from Saxon 9.2 running with -xsdversion:1.0:
>
> Error on line 15 of test.xsd:
> The type DerivedType is defined with xs:all so (in XSD 1.0)
> it cannot be derived by
> extension from a non-empty type
> Schema processing failed: The schema is invalid
>
> but with -xsdversion:1.1 I get:
>
> Schema checking successful.
>
> Regards,
>
> Michael Kay
> http://www.saxonica.com/
> http://twitter.com/michaelhkay
>
>
>
Received on Monday, 30 November 2009 15:42:05 GMT
]]>RE: Reg. <all> model group extension http://xsd.stylusstudio.com/2009Nov/post05001.htm2009-11-30T15:11:09Z
>
> I don't believe you are allowed to extend xs:all in XSD 1.0.
> This has been relaxed in the upcoming 1.1.
Correct (thanks for spotting this, Pete).
After fixing a couple of typos (bad XML end tags), I get the following from
Saxon 9.2 running with -xsdversion:1.0:
Error on line 15 of test.xsd:
The type DerivedType is defined with xs:all so (in XSD 1.0) it cannot be
derived by
extension from a non-empty type
Schema processing failed: The schema is invalid
but with -xsdversion:1.1 I get:
Schema checking successful.
Regards,
Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay
Received on Monday, 30 November 2009 15:11:41 GMT
]]>Re: Reg. <all> model group extension http://xsd.stylusstudio.com/2009Nov/post04001.htm2009-11-30T14:41:06ZI don't believe you are allowed to extend xs:all in XSD 1.0. This has been
relaxed in the upcoming 1.1.
That said, even by Daniel Veillard's own admission, the XML schema
processing in libxml2 is patchy, so it's worth trying on another schema
processor.
HTH,
Pete Cordell
Codalogic Ltd
Interface XML to C++ the easy way using XML C++
data binding to convert XSD schemas to C++ classes.
Visit http://codalogic.com/lmx/ or http://www.xml2cpp.com
for more info
----- Original Message -----
From: "bharath" <bharathkr@huawei.com>
To: "'Michael Kay'" <mike@saxonica.com>; <xmlschema-dev@w3.org>
Cc: <rajithr@huawei.com>; <arathikarki@huawei.com>
Sent: Monday, November 30, 2009 2:26 PM
Subject: RE: Reg. <all> model group extension
> Hi..
> I am getting error in libxml2 as well as altova spy saying that
>
> "An all modelgroup is neither allowed in complexType definition
> "tns:BaseType" nor in its extension tns: DerivedType". "
>
> Can you please lookinto this schema whether it is valid or not.
>
>
> Thanks and Regards,
> Bharath.
>
>
> htipl
> HUAWEI TECHNOLOGIES CO.,LTD. huawei_logo
> <file:///C:/Documents%20and%20Settings/b72392/Application%20Data/Microsoft/S
> ignatures/outlook_huawei_logo_en.jpg>
>
>
> Address: Huawei Industrial Base
> Bantian Longgang
> Shenzhen 518129, P.R.China
> www.huawei.com
> ----------------------------------------------------------------------------
> ---------------------------------------------------------
> This e-mail and its attachments contain confidential information from
> HUAWEI, which
> is intended only for the person or entity whose address is listed above.
> Any
> use of the
> information contained herein in any way (including, but not limited to,
> total or partial
> disclosure, reproduction, or dissemination) by persons other than the
> intended
> recipient(s) is prohibited. If you receive this e-mail in error, please
> notify the sender by
> phone or email immediately and delete it!
>
>
>
> _____
>
> From: Michael Kay [mailto:mike@saxonica.com]
> Sent: Monday, November 30, 2009 7:36 PM
> To: 'bharath'; xmlschema-dev@w3.org
> Cc: rajithr@huawei.com; arathikarki@huawei.com
> Subject: RE: Reg. <all> model group extension
>
>
> It looks OK to me by visual inspection - I haven't tried running it.
>
> Why do you doubt that it's OK?
>
> Regards,
>
> Michael Kay
> http://www.saxonica.com/
> http://twitter.com/michaelhkay
>
>
>
>
>
> _____
>
> From: xmlschema-dev-request@w3.org [mailto:xmlschema-dev-request@w3.org]
> On
> Behalf Of bharath
> Sent: 30 November 2009 13:55
> To: xmlschema-dev@w3.org
> Cc: rajithr@huawei.com; arathikarki@huawei.com
> Subject: Reg. <all> model group extension
>
>
> Hi All,
>
> I have one doubt reg. <all> model group extension.
>
> i have the following schema.
>
> <schema targetNamespace="testschema" xmlns:tns="testschema">
> <complexType name="BaseType">
> <all>
> <element name="a1" type="string"/>
>
> <element name="a2" type="string"/>
> </all>
> </complexType>
>
> <complexType name="DerivedType">
> <complexContent>
> <extension base="tns:BaseType">
> <all>
> <element name="a3" type="string"/>
> </all>
> <extension>
> </complexContent>
> <complexType>
>
> </schema>
>
> Is this extension of the <all> model group correct??
> If not please provide me the reason. Please reply me as soon as possible.
>
>
> Thanks and Regards,
> Bharath.
>
>
Received on Monday, 30 November 2009 14:41:47 GMT
]]>RE: Reg. <all> model group extension http://xsd.stylusstudio.com/2009Nov/post02001.htm2009-11-30T14:06:16ZIt looks OK to me by visual inspection - I haven't tried running it.
Why do you doubt that it's OK?
Regards,
Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay
_____
From: xmlschema-dev-request@w3.org [mailto:xmlschema-dev-request@w3.org] On
Behalf Of bharath
Sent: 30 November 2009 13:55
To: xmlschema-dev@w3.org
Cc: rajithr@huawei.com; arathikarki@huawei.com
Subject: Reg. <all> model group extension
Hi All,
I have one doubt reg. <all> model group extension.
i have the following schema.
<schema targetNamespace="testschema" xmlns:tns="testschema">
<complexType name="BaseType">
<all>
<element name="a1" type="string"/>
<element name="a2" type="string"/>
</all>
</complexType>
<complexType name="DerivedType">
<complexContent>
<extension base="tns:BaseType">
<all>
<element name="a3" type="string"/>
</all>
<extension>
</complexContent>
<complexType>
</schema>
Is this extension of the <all> model group correct??
If not please provide me the reason. Please reply me as soon as possible.
Thanks and Regards,
Bharath.
Received on Monday, 30 November 2009 14:06:51 GMT
]]>[ANN] Python XML Schema Bindings 1.0.0 http://xsd.stylusstudio.com/2009Nov/post00001.htm2009-11-18T17:03:52Z(If the maintainer of http://www.w3.org/XML/Schema#Tools would be so
kind as to add the link to PyXB's home page, I'd appreciate it. Thanks.)
PyXB version 1.0.0 is now available from SourceForge at:
http://sourceforge.net/projects/pyxb/
PyXB (Python XML Schema Bindings; "pixbee") is a pure Python package
that generates Python source code for classes that correspond to data
structures defined by XMLSchema. In concept it is similar to JAXB for
Java and CodeSynthesis XSD for C++. The current release supports XML
Schema 1.0.
Version 1.0.0 is feature-complete and suitable for production
development where validation of incoming and generated documents is
desired. The following schema constructs are supported:
* Class constants corresponding to string enumeration constraints
* Simple and complex type definitions
* List and union datatypes
* Constraints on (simple) datatypes (e.g., minInclusive, length)
* Model groups and attribute groups
* Complex content models (all, sequence, choice); minOccurs and
maxOccurs
* Abstract types, xsi:type, substitution groups
* Nillable elements with xsi:nil
* Namespace qualified attributes and elements
* Documentation annotations present in the schema are converted to
Python docstrings in the generated bindings.
* Pattern constraints (as long as the simple type derives from
something that is represented as a Python string)
The full distribution includes generated bindings for twenty-three
namespaces related to web services (including several versions of SOAP
and WSDL), and twenty-eight namespaces from the Open Geospatial
Consortium's Geographic Information System schema.
For further information and links to the support forum and mailing list,
please consult the documentation available at: http://pyxb.sourceforge.net/
Peter
Received on Thursday, 19 November 2009 10:39:57 GMT
]]>A plea to XSD 1.1 vendors: provide a "switch" to turn on/off vendor-unique extensions http://xsd.stylusstudio.com/2009Nov/post09000.htm2009-11-18T15:29:49Z
Hi Folks,
In XSD 1.1 vendors are allowed to extend the language with additional (vendor-unique) datatypes and facets.
Example: In some countries the decimal point symbol is the comma; so a vendor may provide a new decimal datatype and a new facet for specifying the decimal point symbol:
<xs:simpleType name="money">
<xs:restriction base="vendor:decimal">
<vendor:delimiter value="," />
<xs:restriction>
</xs:simpleType>
This is very useful.
However, this capability represents an uncertainty in what things are in the language ("If you're using this XSD 1.1tool then these x,y,z things are in the language, if you're using that XSD 1.1 tool then these a,b,c things are in the language"). For some of my clients:
uncertainty = risk
For those clients, risk must be mitigated.
Thus, I issue a plea to all XSD 1.1 vendors: please provide a switch to turn on/off vendor-unique extensions.
I believe that providing a switch to turn on/off vendor-unique extension will give vendors a market advantage.
Thanks for your time.
/Roger
Received on Wednesday, 18 November 2009 20:30:23 GMT
]]>Re: Naming in Override Constraints and Semantics http://xsd.stylusstudio.com/2009Nov/post08000.htm2009-11-11T15:02:12ZThanks Henry. Just done.
As I know the WG is not looking for extra work I thought I'd post to the
public list so that members have a low procedure way to object to the
comment if I've really missed the point! That said, I think it's a simple
and useful change to make.
Thanks again,
Pete.
--
=============================================
Pete Cordell
Codalogic Ltd
Interface XML to C++ the easy way using XML C++
data binding to convertXSD schemas to C++ classes.
Visit http://codalogic.com/lmx/ or http://www.xml2cpp.com
for more info
=============================================
----- Original Message -----
From: "Henry S. Thompson" <ht@inf.ed.ac.uk>
To: "Pete Cordell" <petexmldev@codalogic.com>
Cc: <xmlschema-dev@w3.org>
Sent: Wednesday, November 11, 2009 9:40 AM
Subject: Re: Naming in Override Constraints and Semantics
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Requests for changes to the spec should go to
www-xml-schema-comments@w3.org or into Buzilla -- they may get
overlooked if they are only sent here.
I'd suggest you reduce the length of your requested new names, to,
say, Dold and Dnew. . .
ht
- --
Henry S. Thompson, School of Informatics, University of Edinburgh
Half-time member of W3C Team
10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 651-1426, 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]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFK+oaRkjnJixAXWBoRAjCyAJ9xWKNKnDOdCgsVHifHkSH+r5oDdwCcCsMy
6PycvCIKjDgwQwoHHLQRtSM=
=045d
-----END PGP SIGNATURE-----
Received on Wednesday, 11 November 2009 15:02:48 GMT
]]>Re: Naming in Override Constraints and Semantics http://xsd.stylusstudio.com/2009Nov/post07000.htm2009-11-11T09:40:29Z-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Requests for changes to the spec should go to
www-xml-schema-comments@w3.org or into Buzilla -- they may get
overlooked if they are only sent here.
I'd suggest you reduce the length of your requested new names, to,
say, Dold and Dnew. . .
ht
- --
Henry S. Thompson, School of Informatics, University of Edinburgh
Half-time member of W3C Team
10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 651-1426, 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]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFK+oaRkjnJixAXWBoRAjCyAJ9xWKNKnDOdCgsVHifHkSH+r5oDdwCcCsMy
6PycvCIKjDgwQwoHHLQRtSM=
=045d
-----END PGP SIGNATURE-----
Received on Wednesday, 11 November 2009 09:41:13 GMT
]]>Naming in Override Constraints and Semantics http://xsd.stylusstudio.com/2009Nov/post06000.htm2009-11-10T17:57:56ZIn "Schema Representation Constraint: Override Constraints and Semantics",
is there any chance that:
- D1 could be changed to Doverridden and
- D2 could be changed to Doverriding?
Then:
2 One of the following must be true:
2.1 D2 has a targetNamespace [attribute], and its ·actual value· is
identical to the ·actual value· of the targetNamespace [attribute] of D1
(which must have such an [attribute]).
2.2 Neither D2 nor D1 have a targetNamespace [attribute].
2.3 D2 has no targetNamespace [attribute] (but D1 does).
becomes:
2 One of the following must be true:
2.1 Doverriding has a targetNamespace [attribute], and its ·actual value· is
identical to the ·actual value· of the targetNamespace [attribute] of
Doverridden (which must have such an [attribute]).
2.2 Neither Doverriding nor Doverridden have a targetNamespace [attribute].
2.3 Doverriding has no targetNamespace [attribute] (but Doverridden does).
This is a lot easier on the old brain!
There are possibly similar name changes that could be made that would make
the life of the reader much easier.
Thanks,
Pete.
--
=============================================
Pete Cordell
Codalogic Ltd
Interface XML to C++ the easy way using XML C++
data binding to convert XSD schemas to C++ classes.
Visit http://codalogic.com/lmx/ or http://www.xml2cpp.com
for more info
=============================================
Received on Tuesday, 10 November 2009 17:58:55 GMT
]]>RE: Possible to restrict top-level xs:element names? http://xsd.stylusstudio.com/2009Nov/post05000.htm2009-11-07T14:24:52ZThank you all for your valuable feedback. I think Henry put it most
succintly:
"The spec doesn't provide a mechanism by which a schema can constrain the
document element of schema-valid documents."
That's what I was wanting to know. I apologise if I used confusing
terminology in trying to explain my problem!
Regards,
Richard.
--
View this message in context: http://old.nabble.com/Possible-to-restrict-top-level-xs%3Aelement-names--tp26227610p26249237.html
Sent from the w3.org - xmlschema-devmailing list archive at Nabble.com.
Received on Saturday, 7 November 2009 22:26:09 GMT
]]>RE: Possible to restrict top-level xs:element names? http://xsd.stylusstudio.com/2009Nov/post04000.htm2009-11-07T10:25:13Z> (b) make sure your processor distinguishes between elements
> with [validity]=invalid and those with [validity]=notKnown
> (again, how you do this is between you and your processor,
> and out of scope for the XSD spec); and
You might like to note that Saxon's schema processor, and perhaps some other
products, expose this distinction by allowing you to select "strict" or
"lax" validation. Strict validation fails if the outcome is
[validity]=notKnown, whereas lax validation succeeds.
Regards,
Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay
Received on Saturday, 7 November 2009 10:25:46 GMT
]]>Re: Possible to restrict top-level xs:element names? http://xsd.stylusstudio.com/2009Nov/post02000.htm2009-11-06T19:35:27Z-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The spec doesn't provide a mechanism by which a schema can constrain
the document element of schema-valid documents.
It _does_ provide license for conformant processors to do
schema-validity assessment with such a constraint in place [1].
Different processors allow users to invoke this kind of processing in
different ways -- what validator are you using?
ht
[1] http://www.w3.org/TR/xmlschema-1/#c-res
- --
Henry S. Thompson, School of Informatics, University of Edinburgh
Half-time member of W3C Team
10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 651-1426, 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]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFK9Hp/kjnJixAXWBoRAkmzAJ4q7YYJ84l6UmdhZ+gdbrpNdEr9BwCeIxS/
EM49iXoq0GTVWxYb0Vv+bQI=
=muE/
-----END PGP SIGNATURE-----
Received on Friday, 6 November 2009 19:36:17 GMT
]]>Re: Possible to restrict top-level xs:element names? http://xsd.stylusstudio.com/2009Nov/post03000.htm2009-11-06T17:35:19ZOn 5 Nov 2009, at 23:58 , kennardconsulting wrote:
>
> I'm generating a bunch of XML Schemas that look roughly like:
>
> <xs:schema ...>
> <xs:element name="foo"/>
> <xs:element name="bar"/>
> </xs:schema>
>
> You can see the actual ones http://metawidget.org/xsd here . My
> question
> is, this schema allows me to declare 'foo' and 'bar' in my XML
> document, but
> doesn't restrict me declaring, say, 'baz'.
I'm not quite sure what you're saying. Where I come from, it is
natural to speak of declaring 'foo' and 'bar' elements in a schema
document (as is done in the skeleton you give), but odd to speak
of 'declaring' elements in the XML instance being validated.
If you mean "how do I prevent someone else writing a schema
document for my target namespace and including a top-level baz
element in it?", the answer is that you can't prevent other
people from writing what they like in documents on their own
hard disks. The world is just structured that way.
On the other hand, you don't have to use the schema documents on
their hard disks when you validate. If you want to ensure that
in a particular validation episode 'foo' and 'bar' will be
global elements in the target namespace, and 'baz' won't be,
you just need to arrange with your schema validator, at invocation
time, that it should read your schema documents, and not the
ones on other people's disks that include declaration for
'baz'. How you arrange with a validator to read certain schema
documents and not read others is out of scope of the schema
language itself; if a particular validator does not allow you
to control things with the degree of precision you need, it's
a quality issue and you should look for a new validator.
If on the other hand you mean "how do I keep someone from
using a 'baz' element in my namespace?", again, the universe
is so structured that nothing you or XSD or any other schema
language can do could possibly prevent that.
The most you can do is try to arrange that such a usage
counts as invalid when the document is validated against your
schema. So consider the question "how do I ensure that when
a user uses a 'baz' element in my namespace, it's marked
invalid?" The answer is, roughly:
(a) tell the validator to read your schema document and
not some bogus one which defines 'baz' (see above);
(b) make sure your processor distinguishes between elements
with [validity]=invalid and those with [validity]=notKnown
(again, how you do this is between you and your processor,
and out of scope for the XSD spec); and
(c) make sure your own code that invokes the validator rejects
the cases where [validity]=notKnown.
> I was expecting something like...
>
> <xs:schema final="#all">
>
> ....so that I could 'close' the set of possible xs:element names. Or
> maybe
> that the set was closed by default and I'd need...
>
> <xs:schema ...>
> <xs:element name="foo"/>
> <xs:element name="bar"/>
> <xs:any />
> </xs:schema>
>
> ....to make it open. But instead the set of top-level xs:element names
> appears 'open' by default and I can't find a way to close it? I have
> looked
> all over the specs and in this forum, sorry if I'm being dumb.
I'm not sure what you mean by open and closed sets of elements
(or element names) here. I'm also not sure whether by "top-level"
you mean "can be used as the root element of a document" or
"defined on the top level of a schema document; not local to a
complex type". But in a way, I guess, it doesn't really matter:
XSD's design says, essentially, that the way you specify "these
declarations, and no others" is to say just that, but at validation
time, not at schema specification time.
I hope this helps.
--
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com
* http://cmsmcq.com/mib
* http://balisage.net
****************************************************************
Received on Saturday, 7 November 2009 00:35:51 GMT
]]>Re: Possible to restrict top-level xs:element names? http://xsd.stylusstudio.com/2009Nov/post01000.htm2009-11-06T14:30:11ZI'm not quite sure what you are asking. Are you trying to restrict how
your schema can be extended, or are you trying to restrict what is
allowed in an instance document?
Perhaps you have a conceptual misunderstanding? Note that
<xs:schema ...>
<xs:element name="foo"/>
<xs:element name="bar"/>
</xs:schema>
is not the same as
<xs:schema ...>
<xs:choice>
<xs:element name="foo"/>
<xs:element name="bar"/>
</xs:choice>
</xs:schema>
(which isn't legal btw).
That is, the children of your <schema> element do not represent a model
for your instance documents, which is perhaps how you are thinking of
it? Rather, they declare the elements, attributes, and types according
to which an instance document may be validated. (Note by the way, that
there are different approaches to validating documents against schemas,
see
http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#validation_outcome).
I don't believe you can prevent someone from including your schema
document into theirs while at the same time adding more global elements,
if that's what you are trying to avoid.
Kevin
--
Objective Systems, Inc.
REAL WORLD ASN.1 AND XML SOLUTIONS
Tel: +1 (484) 875-9841
Fax: +1 (484) 875-9830
Toll-free: (877) 307-6855 (USA only)
http://www.obj-sys.com
On 11/6/2009 1:58 AM, kennardconsulting wrote:
> Hi guys,
>
> I'm generating a bunch of XML Schemas that look roughly like:
>
> <xs:schema ...>
> <xs:element name="foo"/>
> <xs:element name="bar"/>
> </xs:schema>
>
> You can see the actual ones http://metawidget.org/xsd here . My question
> is, this schema allows me to declare 'foo' and 'bar' in my XML document, but
> doesn't restrict me declaring, say, 'baz'. I was expecting something like...
>
> <xs:schema final="#all">
>
> ....so that I could 'close' the set of possible xs:element names. Or maybe
> that the set was closed by default and I'd need...
>
> <xs:schema ...>
> <xs:element name="foo"/>
> <xs:element name="bar"/>
> <xs:any />
> </xs:schema>
>
> ....to make it open. But instead the set of top-level xs:element names
> appears 'open' by default and I can't find a way to close it? I have looked
> all over the specs and in this forum, sorry if I'm being dumb.
>
> Regards,
>
> Richard.
>
Received on Friday, 6 November 2009 19:32:40 GMT
]]>Possible to restrict top-level xs:element names? http://xsd.stylusstudio.com/2009Nov/post00000.htm2009-11-05T22:58:55ZHi guys,
I'm generating a bunch of XML Schemas that look roughly like:
<xs:schema ...>
<xs:element name="foo"/>
<xs:element name="bar"/>
</xs:schema>
You can see the actual ones http://metawidget.org/xsd here . My question
is, this schema allows me to declare 'foo' and 'bar' in my XML document, but
doesn't restrict me declaring, say, 'baz'. I was expecting something like...
<xs:schema final="#all">
....so that I could 'close' the set of possible xs:element names. Or maybe
that the set was closed by default and I'd need...
<xs:schema ...>
<xs:element name="foo"/>
<xs:element name="bar"/>
<xs:any />
</xs:schema>
....to make it open. But instead the set of top-level xs:element names
appears 'open' by default and I can't find a way to close it? I have looked
all over the specs and in this forum, sorry if I'm being dumb.
Regards,
Richard.
--
View this message in context: http://old.nabble.com/Possible-to-restrict-top-level-xs%3Aelement-names--tp26227610p26227610.html
Sent from the w3.org - xmlschema-devmailing list archive at Nabble.com.
Received on Friday, 6 November 2009 18:52:00 GMT
]]>[ANN] Altova announces v2010 of the MissionKit tool suite http://xsd.stylusstudio.com/2009Oct/post09005.htm2009-10-29T15:38:25ZAltova is pleased to announce general availability version 2010 of its
MissionKit XML, database, and UML tools. v2010 is our MOST WANTED
release and includes over 70 new customer-requested features. Just a few
of these include:
* Support for WSDL 2.0, JSON, and SysML technologies
* New stylesheet design paradigm with advanced support for electronic
form design
* Enhanced XBRLfunctionality
* Database schema comparison
* And much more
More info and screenshots are available at
<http://www.altova.com/whatsnew.html>
Download a fully functional free trial at
<http://www.altova.com/download.html>
Best regards,
Liz
Liz Andrews
Technical Marketing Manager
Altova, Inc.
www.altova.com
________________________________
This e-mail and any attachments are intended only for the person/entity
to which they are addressed and may contain confidential and/or
privileged material. If you received this in error, please notify the
sender and delete the message.
Liz Andrews
Technical Marketing Manager
Altova, Inc.
www.altova.com
________________________________
This e-mail and any attachments are intended only for the person/entity
to which they are addressed and may contain confidential and/or
privileged material. If you received this in error, please notify the
sender and delete the message.
Received on Thursday, 29 October 2009 19:39:06 GMT
]]>Re: redefine and target namespace http://xsd.stylusstudio.com/2009Oct/post07005.htm2009-10-26T14:52:05Z-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Florent Georges writes:
> Henry S. Thompson wrote:
>
>> Without going into tedious and confidential details about
>> personalities and working group discussions, suffice it to say
>> that the design we have was the only one that included both
>> possibilities which the WG could reach consensus on.
>
> Yes, but that does not answer the interesting question: why the
> chosen default value ;-)
That was part of the compromise.
ht
- --
Henry S. Thompson, School of Informatics, University of Edinburgh
Half-time member of W3C Team
10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 651-1426, 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]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFK5beVkjnJixAXWBoRAoT5AJ4yFDcwJ5ffeptvNEzg6ORziuap5gCdFrbr
df9/0oDB1kNHtEXZPaHqEks=
=ciuI
-----END PGP SIGNATURE-----
Received on Monday, 26 October 2009 14:54:41 GMT
]]>Re: redefine and target namespace http://xsd.stylusstudio.com/2009Oct/post06005.htm2009-10-26T14:20:39ZHenry S. Thompson wrote:
Hi,
> Without going into tedious and confidential details about
> personalities and working group discussions, suffice it to say
> that the design we have was the only one that included both
> possibilities which the WG could reach consensus on.
Yes, but that does not answer the interesting question: why the
chosen default value ;-)
Regards,
--
Florent Georges
http://www.fgeorges.org/
Received on Monday, 26 October 2009 14:21:16 GMT
]]>Re: redefine and target namespace http://xsd.stylusstudio.com/2009Oct/post05005.htm2009-10-26T11:56:14Z-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Michael Kay writes:
> Yes. I've never heard an adequate explanation of why this extraordinary
> decision was made, but in practice everyone changes the default by using
> elementFormDefault="qualified".
At the time the spec. was written, the community was pretty evenly
divided between people who thought the attribute model (i.e. not in a
namespace as such) was right for leaf node elements as well, and those
who thought that all elements should be qualified.
Without going into tedious and confidential details about
personalities and working group discussions, suffice it to say that
the design we have was the only one that included both possibilities
which the WG could reach consensus on.
ht
- --
Henry S. Thompson, School of Informatics, University of Edinburgh
Half-time member of W3C Team
10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 651-1426, 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]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFK5Y5ekjnJixAXWBoRAh2UAJ4gBVgrOq4C+DK22kFTJNRvnLkSFwCfZnsJ
jgNXeNgag92u+CLvC5gXK9o=
=yYHE
-----END PGP SIGNATURE-----
Received on Monday, 26 October 2009 11:57:06 GMT
]]>Re: redefine and target namespace http://xsd.stylusstudio.com/2009Oct/post08005.htm2009-10-26T11:22:14ZHenry Thompson writes:
> That was part of the compromise.
Stated differently: you can infer that there were a significant number of
people involved who strongly took the opposite position from yours, and
the default you see was in deference to their views of what the community
needed. As already noted, it was a long and difficult discussion, with
strongly held opinions on both sides. I don't think anyone thought the
resulting design was particularly appealing, but given the strongly
divergent opinions about what users needed and/or about how namespaces
were supposed to be used, the design had the advantage of letting users
choose. FWIW: I tend to sympathize with George's feeling that most users
do want the qualified idiom, that qualified would have been a better
default, etc. Still, it's way too late to reopen it now, and there are
schemas out in the wild that use both options as far as I know.
Noah
--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------
ht@inf.ed.ac.uk (Henry S. Thompson)
Sent by: xmlschema-dev-request@w3.org
10/26/2009 10:52 AM
To: lists@fgeorges.org
cc: Michael Kay <mike@saxonica.com>, xmlschema-dev@w3.org,
(bcc: Noah Mendelsohn/Cambridge/IBM)
Subject: Re: redefine and target namespace
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Florent Georges writes:
> Henry S. Thompson wrote:
>
>> Without going into tedious and confidential details about
>> personalities and working group discussions, suffice it to say
>> that the design we have was the only one that included both
>> possibilities which the WG could reach consensus on.
>
> Yes, but that does not answer the interesting question: why the
> chosen default value ;-)
That was part of the compromise.
ht
- --
Henry S. Thompson, School of Informatics, University of Edinburgh
Half-time member of W3C Team
10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 651-1426, 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]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFK5beVkjnJixAXWBoRAoT5AJ4yFDcwJ5ffeptvNEzg6ORziuap5gCdFrbr
df9/0oDB1kNHtEXZPaHqEks=
=ciuI
-----END PGP SIGNATURE-----
Received on Monday, 26 October 2009 15:23:04 GMT
]]>Re: redefine and target namespace http://xsd.stylusstudio.com/2009Oct/post04005.htm2009-10-25T22:39:37ZMichael Kay wrote:
Hi,
> > I thought the element 'b' was defined in the target
> > namespace, but it seems it has to be in no namespace.
> Just as if you didn't use redefine, your local element
> declaration will only be in the target namespace if you specify
> elementFormDefault="qualified"
<blush>Ouch!</blush> It's been a long time since I've been
fooled by this one. I guess I was focused on the redefine...
Sorry for the noise and thanks for the quick answer!
Regards,
--
Florent Georges
http://www.fgeorges.org/
Received on Sunday, 25 October 2009 22:40:11 GMT
]]>RE: redefine and target namespace http://xsd.stylusstudio.com/2009Oct/post03005.htm2009-10-25T18:51:17Z
> I thought the element 'b' was defined in the target namespace, but it
seems it has to be in no namespace.
Just as if you didn't use redefine, your local element declaration will only
be in the target namespace if you specify elementFormDefault="qualified" on
your xs:schema element. (Or, of course, form="qualified" on the local
element declaration itself, but no-one ever does that.)
> Is it really the intent of the spec?
Yes. I've never heard an adequate explanation of why this extraordinary
decision was made, but in practice everyone changes the default by using
elementFormDefault="qualified".
Regards,
Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay
Received on Sunday, 25 October 2009 18:51:50 GMT
]]>redefine and target namespace http://xsd.stylusstudio.com/2009Oct/post02005.htm2009-10-25T18:05:41Z Hi,
I have a schema document that redefines a complex type as
following:
<xs:redefine schemaLocation="redefine.xsd">
<xs:complexType name="root">
<xs:complexContent>
<xs:extension base="tns:root">
<xs:sequence>
<xs:element name="b" type="xs:string"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:redefine>
I thought the element 'b' was defined in the target namespace,
but it seems it has to be in no namespace. Is it really the
intent of the spec? Did I do anything wrong? I use Xerces 2 for
Java (as in Java SE 6.)
redefine.xsd:
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:tns="tns"
targetNamespace="tns"
elementFormDefault="qualified">
<xs:element name="root" type="tns:root"/>
<xs:complexType name="root">
<xs:sequence>
<xs:element name="a" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:schema>
redefine-red.xsd:
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
targetNamespace="tns"
xmlns:tns="tns">
<xs:redefine schemaLocation="redefine.xsd">
<xs:complexType name="root">
<xs:complexContent>
<xs:extension base="tns:root">
<xs:sequence>
<xs:element name="b" type="xs:string"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:redefine>
<xs:element name="redefined" type="tns:root"/>
</xs:schema>
Valid redefine.xml:
<tns:redefined xmlns:tns="tns">
<tns:a>bla</tns:a>
<b>bla</b>
</tns:redefined>
Expected valid redefine.xml (but actually invalid):
<redefined xmlns="tns">
<a>bla</a>
<b>bla</b>
</redefined>
Regards,
--
Florent Georges
http://www.fgeorges.org/
Received on Sunday, 25 October 2009 18:06:15 GMT
]]>Re: Resolution of "ref" attribute in case of <override> http://xsd.stylusstudio.com/2009Oct/post01005.htm2009-10-22T10:18:39ZVery well. Thank you, Michael and Michael.
On 10/22/2009 4:08 AM, Michael Kay wrote:
>> How will the prefix in the ref attribute in the
>> attributeGroup element be handled? If D2' is the result of
>> applying the xs:override transform, and D2' contains an
>> element information item that is identical to the one for the
>> <attributeGroup>, I expect it will have [in-scope namespaces]
>> based on what we see above; namely, the qrs prefix will
>> necessarily resolve to "uri:example.com". Is that correct?
>>
>
> Yes. In fact, this doesn't even depend on the stylesheet being schema-aware
> and on @ref being known to be a QName. The element is copied using
> <xsl:copy-of>, which copies all the in-scope namespaces of an element,
> including therefore the namespace binding for "qrs".
>
>> Also, a second question. I don't speak XSLT, but the
>> stylesheet given for the transformation for xs:override
>> includes a comment that says :
>>
>> <!--* change xs:override elements: children which match
>> * children of $overrideElement are replaced, others are
>> * kept, and at the end all children of $overrideElement
>> * not already inserted are added.
>> *-->
>>
>> The "at the end all children..." clause doesn't appear to be
>> consistent with the description that precedes the stylesheet.
>> Specifically, I don't see where a child of O1 that does not
>> correspond to a child of D2
>> would be put into D2'. Perhaps I misunderstand the comment,
>> or perhaps
>> it isn't consistent with the XSLT that is there (again, I
>> don't speak XSLT). Is there an inconsistency here?
>>
>
> I think Michael Sperberg McQueen has explained this part. It is complex and
> my brain aches a little every time I look at it, but I think I have
> convinced myself that it works. It would benefit, however, from some serious
> testing: there is an assumption that we will produce tests before exiting
> CR.
>
> Regards,
>
> Michael Kay
> http://www.saxonica.com/
> http://twitter.com/michaelhkay
>
>
>
>
Received on Thursday, 22 October 2009 14:20:56 GMT
]]>RE: Resolution of "ref" attribute in case of <override> http://xsd.stylusstudio.com/2009Oct/post00005.htm2009-10-22T09:08:12Z>
> How will the prefix in the ref attribute in the
> attributeGroup element be handled? If D2' is the result of
> applying the xs:override transform, and D2' contains an
> element information item that is identical to the one for the
> <attributeGroup>, I expect it will have [in-scope namespaces]
> based on what we see above; namely, the qrs prefix will
> necessarily resolve to "uri:example.com". Is that correct?
Yes. In fact, this doesn't even depend on the stylesheet being schema-aware
and on @ref being known to be a QName. The element is copied using
<xsl:copy-of>, which copies all the in-scope namespaces of an element,
including therefore the namespace binding for "qrs".
>
> Also, a second question. I don't speak XSLT, but the
> stylesheet given for the transformation for xs:override
> includes a comment that says :
>
> <!--* change xs:override elements: children which match
> * children of $overrideElement are replaced, others are
> * kept, and at the end all children of $overrideElement
> * not already inserted are added.
> *-->
>
> The "at the end all children..." clause doesn't appear to be
> consistent with the description that precedes the stylesheet.
> Specifically, I don't see where a child of O1 that does not
> correspond to a child of D2
> would be put into D2'. Perhaps I misunderstand the comment,
> or perhaps
> it isn't consistent with the XSLT that is there (again, I
> don't speak XSLT). Is there an inconsistency here?
I think Michael Sperberg McQueen has explained this part. It is complex and
my brain aches a little every time I look at it, but I think I have
convinced myself that it works. It would benefit, however, from some serious
testing: there is an assumption that we will produce tests before exiting
CR.
Regards,
Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay
Received on Thursday, 22 October 2009 08:08:58 GMT
]]>Re: Resolution of "ref" attribute in case of <override> http://xsd.stylusstudio.com/2009Oct/post09004.htm2009-10-21T18:11:48ZOn 21 Oct 2009, at 15:22 , Kevin Braun wrote:
> Here's an XSD 1.1 <override> question.
> Suppose I have:
> <schema ... xmlns:qrs="uri:example.com">
> <override ...>
> <complexType name="SomeType">
> <attributeGroup ref="qrs:abc"/>
> </complexType>
> </override>
> ...
> </schema>
> How will the prefix in the ref attribute in the attributeGroup
> element be handled?
> If D2' is the result of applying the xs:override transform, and D2'
> contains an element information item that is identical to the one
> for the <attributeGroup>, I expect it will have [in-scope
> namespaces] based on what we see above; namely, the qrs prefix will
> necessarily resolve to "uri:example.com". Is that correct?
That's certainly the intent. The namespace fixup rules of XSLT are
complicated enough that I don't want to say more about how it works
in detailuntil I have a chance to work the example through in more
detail. But at a high level, the stylesheet knows the type of
attributeGroup/@ref, so it knows there are QNames around which may
depend on the current namespace bindings. And when the node is
re-serialized in its new context, it should not have lost any
namespace bindings. (The prefix may change, of course, but not the
expanded name denoted by qrs:abc.)
> Also, a second question. I don't speak XSLT, but the stylesheet
> given for the transformation for xs:override includes a comment
> that says :
> <!--* change xs:override elements: children which match
> * children of $overrideElement are replaced, others are
> * kept, and at the end all children of $overrideElement
> * not already inserted are added.
> *-->
> The "at the end all children..." clause doesn't appear to be
> consistent with the description that precedes the stylesheet.
> Specifically, I don't see where a child of O1 that does not
> correspond to a child of D2 would be put into D2'. Perhaps I
> misunderstand the comment, or perhaps it isn't consistent with the
> XSLT that is there (again, I don't speak XSLT). Is there an
> inconsistency here?
The comment correctly describes the template which follows it, I
think. And it also matches the behavior described in rule 4 of the
prose description.
The template applies to xs:override elements within D2, so we are
dealing with two override elements: O1, which is the override we are
trying to handle by performing the transformation, and E2 (the
override child of D2), which is in the process of being transformed
into a new override element O2, which will appear within D2'.
O2 contains (1) children corresponding to the children of E2. If a
particular child of E2 matches some child of O1, then what O2
contains is the child of O1 (the child of E2 has been overridden by
the child of O1). If a particular child of E2 matches no child of
O1, then O2 has that child unchanged.
O2 also contains (2) children corresponding to the children of O1.
If a child of O1 matches a child of E2, it's present in O2 as already
described above. If a child of O1 matches no child of E2, it's
copied into O2 without change.
Example:
Schema document D1 overrides schema document D2, and its override
element contains declarations for elements A, B, and C.
<schema xmlns="http://www.w3.org/2001/XMLSchema">
<override id="d1o" schemaLocation="D2.xsd">
<element name="A" type="anyURI"/>
<element name="B" type="boolean"/>
<element name="C" type="decimal"/>
</override>
</schema>
Schema document D2 overrides schema document D3, and the override
element contains declarations for elements C and D.
<schema xmlns="http://www.w3.org/2001/XMLSchema">
<override id="d2o" schemaLocation="D3.xsd">
<element name="C" type="double"/>
<element name="D" type="duration"/>
</override>
</schema>
Schema document D3 declares elements A, B, C, D, and E.
<schema xmlns="http://www.w3.org/2001/XMLSchema">
<element name="A" />
<element name="B" />
<element name="C" />
<element name="D" />
<element name="E" />
</schema>
Observe first that the end result needs to have A, B, C, and D
declared as anyURI, boolean, decimal, and duration, respectively.
The first draft of override said, essentially, "That's too
complicated, it's not going to happen", and override only affected
elements declared in D2. The result here would have been that of all
the overrides in D1, only the override of C would have had any
effect. (At least, that's my recollection; I have not gone back to
review the details of the original proposal.)
The WG was troubled by the inconvenience this represented, and wanted
the overrides in D1 to affect not only declarations in D2 but
declarations in documents referenced by D2. We spent some time
working out how to make this happen; the mechanism in the stylesheet
is the result.
The effect of the override of D2 in D1 is, according to the spec, the
same as an include of the transformed schema document D2', which
would look something like this:
<schema xmlns="http://www.w3.org/2001/XMLSchema">
<override id="d2o" schemaLocation="D3.xsd">
<element name="C" type="decimal"/>
<element name="D" type="duration"/>
<element name="A" type="anyURI"/>
<element name="B" type="boolean"/>
</override>
</schema>
Note that the overrides for A and B are included here, even though
they matched nothing in override d2o. They are needed to ensure
that A and B are overridden WHEREVER they were declared.
The meaning of the override in D2' is, again, the same as the meaning
of an include on a transformed target D3', reading:
<schema xmlns="http://www.w3.org/2001/XMLSchema">
<element name="A" type="anyURI"/>
<element name="B" type="boolean"/>
<element name="C" type="decimal"/>
<element name="D" type="duration"/>
<element name="E" />
</schema>
If we rewrite the overriding schema documents as well, to show the
change from override to include, we end up with an imaginare D1'
reading
<schema xmlns="http://www.w3.org/2001/XMLSchema">
<include id="d1o" schemaLocation="D2''.xsd"/>
</schema>
And a D2'' reading
<schema xmlns="http://www.w3.org/2001/XMLSchema">
<include id="d2o" schemaLocation="D3'.xsd"/>
</schema>
If the unmatched overrides of d1o had NOT been copied into the
modified version of d2o, then the final result would have had
a D3' of the form
<schema xmlns="http://www.w3.org/2001/XMLSchema">
<element name="A"/>
<element name="B"/>
<element name="C" type="decimal"/>
<element name="D" type="duration"/>
<element name="E" />
</schema>
By copying even the unmatched children of O1 into O2, we ensure that
the declarations of O1 will override other declarations of the same
component name, no matter where those other declarations occur in the
target set of O1. The transformation of include elements into
overide elements serves the same purpose.
I hope this helps.
--
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com
* http://cmsmcq.com/mib
* http://balisage.net
****************************************************************
Received on Thursday, 22 October 2009 00:12:20 GMT
]]>Resolution of "ref" attribute in case of <override> http://xsd.stylusstudio.com/2009Oct/post08004.htm2009-10-21T17:22:02ZHi,
Here's an XSD 1.1 <override> question.
Suppose I have:
<schema ... xmlns:qrs="uri:example.com">
<override ...>
<complexType name="SomeType">
<attributeGroup ref="qrs:abc"/>
</complexType>
</override>
...
</schema>
How will the prefix in the ref attribute in the attributeGroup element
be handled? If D2' is the result of applying the xs:override transform,
and D2' contains an element information item that is identical to the
one for the <attributeGroup>, I expect it will have [in-scope
namespaces] based on what we see above; namely, the qrs prefix will
necessarily resolve to "uri:example.com". Is that correct?
Also, a second question. I don't speak XSLT, but the stylesheet given
for the transformation for xs:override includes a comment that says :
<!--* change xs:override elements: children which match
* children of $overrideElement are replaced, others are
* kept, and at the end all children of $overrideElement
* not already inserted are added.
*-->
The "at the end all children..." clause doesn't appear to be consistent
with the description that precedes the stylesheet. Specifically, I
don't see where a child of O1 that does not correspond to a child of D2
would be put into D2'. Perhaps I misunderstand the comment, or perhaps
it isn't consistent with the XSLT that is there (again, I don't speak
XSLT). Is there an inconsistency here?
Regards,
Keviin
--
Objective Systems, Inc.
REAL WORLD ASN.1 AND XML SOLUTIONS
Tel: +1 (484) 875-9841
Fax: +1 (484) 875-9830
Toll-free: (877) 307-6855 (USA only)
http://www.obj-sys.com
Received on Wednesday, 21 October 2009 21:24:11 GMT
]]>Re: Tools to Generate XSD http://xsd.stylusstudio.com/2009Oct/post07004.htm2009-10-20T22:33:32ZHi Scott,
Trang can generate XML Schema from a set of XML files
http://code.google.com/p/jing-trang/
Best Regards,
George
--
George Cristian Bina
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
http://www.oxygenxml.com
Tsao, Scott wrote:
> I am wondering if there are good tools that would enable (auto)
> generation of XML schema from multiple instances of sample XML document.
>
> It seems to me that one should be able to specify certain parameters for
> the resulting schema, e.g., the design pattern [1] to be followed.
>
> Any comments or suggestions?
>
> [1]
> http://developers.sun.com/jsenterprise/archive/nb_enterprise_pack/reference/techart/design_patterns.html
>
>
> Thanks,
>
> /Scott Tsao/ $BAbThT"(B
> Associate Technical Fellow
> The Boeing Company
>
Received on Tuesday, 20 October 2009 19:34:05 GMT
]]>Set up http://xsd.stylusstudio.com/2009Oct/post06004.htm2009-10-20T10:51:47ZHello.
I downloaded the XSV validator and am a novice user I think because from the hours I have spent looking for set up instructions, I cannot find them. Can you provide the steps I need to follow to set up my validator?
Janell Craig
Business Analyst
Oakland Schools<http://oakland.k12.mi.us> Technology Services<http://www.oakland.k12.mi.us/Departments/TechnologyServices/tabid/932/Default.aspx>
2111 Pontiac Lake Rd.
Waterford, MI 48328
(Ofc) 248-209-2020
(Fax) 248-209-2207
Received on Tuesday, 20 October 2009 17:14:09 GMT
]]>RE: Tools to Generate XSD http://xsd.stylusstudio.com/2009Oct/post05004.htm2009-10-20T09:26:40ZI've had good results on this using Stylus Studio. It works from a single
instance document, but you can always combine multiple instances into one
before you start. There is some control over the design patterns it uses,
but I generally find the default settings are quite usable. Of course you
have to tidy up the generated schema by hand afterwards, for example to make
intelligent decisions about when to use enumerations and patterns in your
simple types, or when to impose a hierarchy of types or substitution groups,
but I find it's often a good way of creating a first cut.
Regards,
Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay
_____
From: xmlschema-dev-request@w3.org [mailto:xmlschema-dev-request@w3.org] On
Behalf Of Tsao, Scott
Sent: 20 October 2009 02:06
To: xmlschema-dev@w3.org
Subject: Tools to Generate XSD from Sample Instances
I am wondering if there are good tools that would enable (auto) generation
of XML schema from multiple instances of sample XML document.
It seems to me that one should be able to specify certain parameters for the
resulting schema, e.g., the design pattern [1] to be followed.
Any comments or suggestions?
[1]
http://developers.sun.com/jsenterprise/archive/nb_enterprise_pack/reference/
techart/design_patterns.html
Thanks,
Scott Tsao $BAbThT"(B
Associate Technical Fellow
The Boeing Company
Received on Tuesday, 20 October 2009 08:27:15 GMT
]]>Re: Tools to Generate XSD http://xsd.stylusstudio.com/2009Oct/post04004.htm2009-10-20T09:07:09ZMy good advice: don't.
or at least, do not expect too much of it.
If you do, you will still need to do a lot of manual work afterwoods improving your schema.
For example, if some attributes are enumerated, how do you know that ? And if you do, how are you sure you have all possible values in your schema ?
How do you know whether the minOccurs for a child element should be 0 or 1 ?
Essentially, automated generation can only be a very first step.
I have seen cases where a believe that XML-Schemas can be generated automatically, without any afterwork, has led to disaster.
For example, the HL7-v3 messages are auto-generated from UML diagrams. At least as far as I know, they are not improved after that by someone who has knowledge of XML-Schema. The result is that the whole stuff is overcomplicated, illogical and even bad XML.
I can advice anyone that wishes to generate XML-Schemas to first learn XML-Schema.
Personally, I prefer to make a good model first (not using UML) and then write the XML-Schema by hand.
Best,
Jozef Aerts
XML4Pharma
----- Original Message -----
From: Tsao, Scott
To: xmlschema-dev@w3.org
Sent: Tuesday, October 20, 2009 3:06 AM
Subject: Tools to Generate XSD from Sample Instances
I am wondering if there are good tools that would enable (auto) generation of XML schema from multiple instances of sample XML document.
It seems to me that one should be able to specify certain parameters for the resulting schema, e.g., the design pattern [1] to be followed.
Any comments or suggestions?
[1] http://developers.sun.com/jsenterprise/archive/nb_enterprise_pack/reference/techart/design_patterns.html
Thanks,
Scott Tsao $BAbThT"(B
Associate Technical Fellow
The Boeing Company
Received on Tuesday, 20 October 2009 07:07:48 GMT
]]>Tools to Generate XSD http://xsd.stylusstudio.com/2009Oct/post03004.htm2009-10-19T18:06:26ZI am wondering if there are good tools that would enable (auto) generation of XMLschema from multiple instances of sample XML document.
It seems to me that one should be able to specify certain parameters for the resulting schema, e.g., the design pattern [1] to be followed.
Any comments or suggestions?
[1] http://developers.sun.com/jsenterprise/archive/nb_enterprise_pack/reference/techart/design_patterns.html
Thanks,
Scott Tsao $BAbThT"(B
Associate Technical Fellow
The Boeing Company
Received on Tuesday, 20 October 2009 01:07:01 GMT
]]>Re: XML schema http://xsd.stylusstudio.com/2009Oct/post01004.htm2009-10-19T17:22:12ZHi, Michael
Would it be something like this?
<xs:attribute name="attribute_id" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:assert test="@attribute_id=Attributes/Attribute/@id or
@attribute_id='id'"> </xs:restriction>
</xs:simpleType>
</xs:attribute>
We are using saxon8 to parse and eclipse and altova xml spy to edit xml.
Are they support 1.1?
Is 1.1 backward compatible with 1.0? I mean: is it enough to change the
header of the xml and xsd or the whole xsd and xml should have been changed?
Is this the correct header for xsd?
<?xml version="1.1" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
Because both eclipse and xml spy says that it is not valid.
Thanks for help.
Regards:
Bence
On Mon, Oct 19, 2009 at 12:27 AM, Michael Kay <mike@saxonica.com> wrote:
> I don't think this can be done in XSD 1.0
>
> It can be done in XSD 1.1, of course, using assertions.
>
> Regards,
>
> Michael Kay
> http://www.saxonica.com/
> http://twitter.com/michaelhkay
>
> > -----Original Message-----
> > From: xmlschema-dev-request@w3.org
> > [mailto:xmlschema-dev-request@w3.org] On Behalf Of btakacs
> > Sent: 18 October 2009 11:32
> > To: xmlschema-dev@w3.org
> > Subject: XML schema
> >
> > Hi
> >
> > I have an xml schema which restricts the
> > Indexes/Tag/@attribute_id values to the ones are defined in
> > the parent element's Attributes/Attribute/@id. Is there a way
> > to extend this and enable one (or more) different static
> > values for example "id"?
> > There are more Indexes/Tag and Attributes/Attribute tags and
> > i would like to use this restriction only for thoose that has
> > the same parent.
> >
> > Here is my current configuration:
> >
> > ....
> > <xs:element name="Attributes">
> > <xs:complexType>
> > <xs:sequence>
> > <xs:element name="Attribute" maxOccurs="unbounded">
> > <xs:complexType>
> > <xs:complexContent>
> > <xs:extension base="Attribute_Type">
> > <xs:attribute name="typedef_id" type="xs:string"
> > use="required"/>
> > </xs:extension>
> > </xs:complexContent>
> > </xs:complexType>
> > </xs:element>
> > </xs:sequence>
> > </xs:complexType>
> > </xs:element>
> > ....
> > <xs:element name="Indexes" minOccurs="0">
> > <xs:complexType>
> > <xs:sequence>
> > <xs:element name="Tag" maxOccurs="unbounded">
> > <xs:complexType>
> > <xs:attribute name="attribute_id" use="required">
> > <xs:simpleType>
> > <xs:restriction base="xs:string">
> > <xs:pattern value="[a-z0-9]([a-z0-9.]|(_[a-z]))*"/>
> > </xs:restriction>
> > </xs:simpleType>
> > </xs:attribute>
> > </xs:complexType>
> > </xs:element>
> > </xs:sequence>
> > </xs:complexType>
> > </xs:element>
> > ....
> > ....
> > <xs:key name="ATTRIBUTE">
> > <xs:selector xpath="Attributes/Attribute"/>
> > <xs:field xpath="@id"/>
> > </xs:key>
> > <xs:keyref name="X001" refer="ATTRIBUTE">
> > <xs:selector xpath="Indexes/Tag"/>
> > <xs:field xpath="@attribute_id"/>
> > </xs:keyref>
> > ....
> >
> >
> > Thanks:
> > Bence
> > --
> > View this message in context:
> > http://www.nabble.com/XML-schema-tp25945562p25945562.html
> > Sent from the w3.org - xmlschema-dev mailing list archive at
> > Nabble.com.
> >
> >
> >
>
>
Received on Monday, 19 October 2009 15:22:47 GMT
]]>RE: XML schema http://xsd.stylusstudio.com/2009Oct/post02004.htm2009-10-19T16:57:10ZThis looks correct (from visual inspection).
To run it you will need Saxon 9.2 or the development version of Xerces (I
can't speak for Xerces). Most schema tools do not yet support XSD 1.1, and
both these two are incomplete implementations.
You don't need to change the xs:schema element in order to use XSD 1.1. All
you need to do is to use an XSD 1.1 processor.
Regards,
Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay
_____
From: xmlschema-dev-request@w3.org [mailto:xmlschema-dev-request@w3.org] On
Behalf Of Bence Takács
Sent: 19 October 2009 16:22
To: xmlschema-dev@w3.org
Subject: Re: XML schema
Hi, Michael
Would it be something like this?
<xs:attribute name="attribute_id" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:assert test="@attribute_id=Attributes/Attribute/@id or
@attribute_id='id'">
</xs:restriction>
</xs:simpleType>
</xs:attribute>
We are using saxon8 to parse and eclipse and altova xml spy to edit xml.
Are they support 1.1?
Is 1.1 backward compatible with 1.0? I mean: is it enough to change the
header of the xml and xsd or the whole xsd and xml should have been changed?
Is this the correct header for xsd?
<?xml version="1.1" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="
unqualified">
Because both eclipse and xml spy says that it is not valid.
Thanks for help.
Regards:
Bence
On Mon, Oct 19, 2009 at 12:27 AM, Michael Kay <mike@saxonica.com> wrote:
I don't think this can be done in XSD 1.0
It can be done in XSD 1.1, of course, using assertions.
Regards,
Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay
> -----Original Message-----
> From: xmlschema-dev-request@w3.org
> [mailto:xmlschema-dev-request@w3.org] On Behalf Of btakacs
> Sent: 18 October 2009 11:32
> To: xmlschema-dev@w3.org
> Subject: XML schema
>
> Hi
>
> I have an xml schema which restricts the
> Indexes/Tag/@attribute_id values to the ones are defined in
> the parent element's Attributes/Attribute/@id. Is there a way
> to extend this and enable one (or more) different static
> values for example "id"?
> There are more Indexes/Tag and Attributes/Attribute tags and
> i would like to use this restriction only for thoose that has
> the same parent.
>
> Here is my current configuration:
>
> ....
> <xs:element name="Attributes">
> <xs:complexType>
> <xs:sequence>
> <xs:element name="Attribute" maxOccurs="unbounded">
> <xs:complexType>
> <xs:complexContent>
> <xs:extension base="Attribute_Type">
> <xs:attribute name="typedef_id" type="xs:string"
> use="required"/>
> </xs:extension>
> </xs:complexContent>
> </xs:complexType>
> </xs:element>
> </xs:sequence>
> </xs:complexType>
> </xs:element>
> ....
> <xs:element name="Indexes" minOccurs="0">
> <xs:complexType>
> <xs:sequence>
> <xs:element name="Tag" maxOccurs="unbounded">
> <xs:complexType>
> <xs:attribute name="attribute_id" use="required">
> <xs:simpleType>
> <xs:restriction base="xs:string">
> <xs:pattern value="[a-z0-9]([a-z0-9.]|(_[a-z]))*"/>
> </xs:restriction>
> </xs:simpleType>
> </xs:attribute>
> </xs:complexType>
> </xs:element>
> </xs:sequence>
> </xs:complexType>
> </xs:element>
> ....
> ....
> <xs:key name="ATTRIBUTE">
> <xs:selector xpath="Attributes/Attribute"/>
> <xs:field xpath="@id"/>
> </xs:key>
> <xs:keyref name="X001" refer="ATTRIBUTE">
> <xs:selector xpath="Indexes/Tag"/>
> <xs:field xpath="@attribute_id"/>
> </xs:keyref>
> ....
>
>
> Thanks:
> Bence
> --
> View this message in context:
> http://www.nabble.com/XML-schema-tp25945562p25945562.html
> Sent from the w3.org - xmlschema-dev mailing list archive at
> Nabble.com.
>
>
>
Received on Monday, 19 October 2009 16:01:54 GMT
]]>Re: Escalation mechanism for different interpretation of W3C XML-Schema specification ? http://xsd.stylusstudio.com/2009Oct/post00004.htm2009-10-19T11:06:23Z-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Michael Kay writes:
>> ... I think this probably means that I would have to augment my
>> list of schema document abstraction to actually make it a
>> list of (schemadoc, targetNamespace) pairs,
>
> That's precisely what I do in my implementation.
And what XSV does -- it is necessary to do this to ensure multiple
chameleon includes into different namespaces works properly.
ht
- --
Henry S. Thompson, School of Informatics, University of Edinburgh
Half-time member of W3C Team
10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 651-1426, 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]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFK3DofkjnJixAXWBoRAmnlAJ9I6XnNvI5W6qSgTPvVOqzLg84aWgCfbYYy
lXbIHxYFMPnudei1X12a7IQ=
=F8lC
-----END PGP SIGNATURE-----
Received on Monday, 19 October 2009 10:06:58 GMT
]]>Re: Escalation mechanism for different interpretation of W3C XML-Schema specification ? http://xsd.stylusstudio.com/2009Oct/post09003.htm2009-10-19T11:02:27Z-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Michael Kay writes:
> Note that dcterms-elem.xsd is reachable from vac.xsd via one route that
> contain a "redefines" step, and by another route that omits this step (but
> which does contain a different redefines step). This is where the
> interpretation of "pervasiveness" is critical: Saxon takes the view that all
> references to components that have been redefined are references to the
> post-redefinition component. In fact the rule introduced in Saxon 9.2 (whose
> incorrect implementation caused the bug) is that every component has a
> redefinition level, so if A redefines B and B redefines C then a given
> component may have redefinition levels of 2, 1, and 0; all references to a
> component name are taken as references to the highest available redefinition
> level, and if there are two different components at the highest redefinition
> level, it's an error (for example, A redefines C, and B also redefines C).
> There's nothing at all in the spec to justify these rules, but it's the only
> way I could find of handling complex redefinition lattices that seemed to
> make sense.
I agree that this is the best available interpretation.
> But the chameleon includes interfere with this (perhaps deliberately).
> Because the common components have been copied into three different
> namespaces, a redefine occurring in one namespace does not affect copies of
> the component in a different namespace. That's Saxon's interpretation,
> anyway.
I agree again.
> In experimenting further with this schema, I discovered that if the two
> imports from vac.xsd are reversed in order, the import of
> owms-classes-redef.xsd has no effect, because it is then importing a
> namespace that is already known to the processor; Saxon ignores the
> schemaLocation URI in this case. So the schema document
> owms-classes-redef.xsd, and the redefinitions that it contains, are simply
> ignored. This makes the situation very fragile: reversing the order of
> imports does not make the processing fail, it just silently compiles a
> different schema. I think this reinforces Henry's argument that if you're
> going to redefine, then there should be one redefining document for each
> namespace, which acts as a gateway to that namespace, and no other
> includes/imports/redefines from elsewhere in the schema should bypass this
> gateway. This schema breaks this rule, and gets away with it only because of
> gateway document is encountered before the bypassing document.
Right -- a useful analysis, thanks.
ht
- --
Henry S. Thompson, School of Informatics, University of Edinburgh
Half-time member of W3C Team
10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 651-1426, 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]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFK3DkzkjnJixAXWBoRAj1IAJ9CVgigXB3xQfzTe9x2OeTovT3E6QCfQNmG
VvXucWnVMMi+LG/RifrT8c4=
=xFVQ
-----END PGP SIGNATURE-----
Received on Monday, 19 October 2009 10:02:59 GMT
]]>RE: XML schema http://xsd.stylusstudio.com/2009Oct/post08003.htm2009-10-18T23:27:50ZI don't think this can be done in XSD 1.0
It can be done in XSD 1.1, of course, using assertions.
Regards,
Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay
> -----Original Message-----
> From: xmlschema-dev-request@w3.org
> [mailto:xmlschema-dev-request@w3.org] On Behalf Of btakacs
> Sent: 18 October 2009 11:32
> To: xmlschema-dev@w3.org
> Subject: XML schema
>
> Hi
>
> I have an xml schema which restricts the
> Indexes/Tag/@attribute_id values to the ones are defined in
> the parent element's Attributes/Attribute/@id. Is there a way
> to extend this and enable one (or more) different static
> values for example "id"?
> There are more Indexes/Tag and Attributes/Attribute tags and
> i would like to use this restriction only for thoose that has
> the same parent.
>
> Here is my current configuration:
>
> ....
> <xs:element name="Attributes">
> <xs:complexType>
> <xs:sequence>
> <xs:element name="Attribute" maxOccurs="unbounded">
> <xs:complexType>
> <xs:complexContent>
> <xs:extension base="Attribute_Type">
> <xs:attribute name="typedef_id" type="xs:string"
> use="required"/>
> </xs:extension>
> </xs:complexContent>
> </xs:complexType>
> </xs:element>
> </xs:sequence>
> </xs:complexType>
> </xs:element>
> ....
> <xs:element name="Indexes" minOccurs="0">
> <xs:complexType>
> <xs:sequence>
> <xs:element name="Tag" maxOccurs="unbounded">
> <xs:complexType>
> <xs:attribute name="attribute_id" use="required">
> <xs:simpleType>
> <xs:restriction base="xs:string">
> <xs:pattern value="[a-z0-9]([a-z0-9.]|(_[a-z]))*"/>
> </xs:restriction>
> </xs:simpleType>
> </xs:attribute>
> </xs:complexType>
> </xs:element>
> </xs:sequence>
> </xs:complexType>
> </xs:element>
> ....
> ....
> <xs:key name="ATTRIBUTE">
> <xs:selector xpath="Attributes/Attribute"/>
> <xs:field xpath="@id"/>
> </xs:key>
> <xs:keyref name="X001" refer="ATTRIBUTE">
> <xs:selector xpath="Indexes/Tag"/>
> <xs:field xpath="@attribute_id"/>
> </xs:keyref>
> ....
>
>
> Thanks:
> Bence
> --
> View this message in context:
> http://www.nabble.com/XML-schema-tp25945562p25945562.html
> Sent from the w3.org - xmlschema-dev mailing list archive at
> Nabble.com.
>
>
>
Received on Sunday, 18 October 2009 22:28:24 GMT
]]>XML schema http://xsd.stylusstudio.com/2009Oct/post07003.htm2009-10-18T03:31:44ZHi
I have an xml schema which restricts the Indexes/Tag/@attribute_id values to
the ones are defined in the parent element's Attributes/Attribute/@id. Is
there a way to extend this and enable one (or more) different static values
for example "id"?
There are more Indexes/Tag and Attributes/Attribute tags and i would like to
use this restriction only for thoose that has the same parent.
Here is my current configuration:
....
<xs:element name="Attributes">
<xs:complexType>
<xs:sequence>
<xs:element name="Attribute" maxOccurs="unbounded">
<xs:complexType>
<xs:complexContent>
<xs:extension base="Attribute_Type">
<xs:attribute name="typedef_id" type="xs:string" use="required"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
....
<xs:element name="Indexes" minOccurs="0">
<xs:complexType>
<xs:sequence>
<xs:element name="Tag" maxOccurs="unbounded">
<xs:complexType>
<xs:attribute name="attribute_id" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value="[a-z0-9]([a-z0-9.]|(_[a-z]))*"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
....
....
<xs:key name="ATTRIBUTE">
<xs:selector xpath="Attributes/Attribute"/>
<xs:field xpath="@id"/>
</xs:key>
<xs:keyref name="X001" refer="ATTRIBUTE">
<xs:selector xpath="Indexes/Tag"/>
<xs:field xpath="@attribute_id"/>
</xs:keyref>
....
Thanks:
Bence
--
View this message in context: http://www.nabble.com/XML-schema-tp25945562p25945562.html
Sent from the w3.org - xmlschema-devmailing list archive at Nabble.com.
Received on Sunday, 18 October 2009 21:30:47 GMT
]]>RE: Escalation mechanism for different interpretation of W3C XML-Schema specification ? http://xsd.stylusstudio.com/2009Oct/post05003.htm2009-10-16T22:22:09Z
> -----Original Message-----
> From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com]
> Sent: 16 October 2009 21:35
> To: Michael Kay
> Cc: 'Henry S. Thompson'; 'XMLSchema at XML4Pharma';
> xmlschema-dev@w3.org
> Subject: RE: Escalation mechanism for different
> interpretation of W3C XML-Schema specification ?
>
> Michal Kay writes;
>
> > It's not clear what answers it gives for more complex redefinition
> > graphs.
>
> Well, it's been a long time since I've looked at it. I guess
> I assume that all redefinition graphs are in fact trees, I.e.
> each redefine can redefine only one thing
Well, there's a graph of schema documents, and a graph of components. If
there's a cycle in the graph of schema documents then there's potential (but
not the necessity) of a cycle at the level of components. A cycle at the
component level is clearly a nonsense, and my inclination is that the same
is true at the document level.
Even without cycles, though, it's not clear to me how ACSOOD handles:
A includes B
A includes C
B redefines X defining a restriction of type T
C redefines X defining a (different) restriction of type T
Perhaps you just let it be caught by the general ban on duplicate
components. But unless you're careful about the wording, that ban also
catches you out on a linear chain of redefinitions.
I noted the statement in your proposal: "Note that the information needed to
determine a redeclaration prototype is easily determined from the
<redefine>ing XML schema document; the text of a redeclaration always
explicitly refers to the particular schema document containing
(specification of) the component being redefined. " I was surprised to see
this, but I now see that the spec does say (in Schema Representation
Constraint: Individual Component Redefinition) "In all cases there must be a
top-level definition item of the appropriate name and kind in the
<redefine>d schema document." I now realise I haven't been enforcing that
rule: I only require it to be present in "the schema corresponding to" the
<redefine>d schema document. If A includes B, and R redefines A, then I
allow R to contain redefinitions of components that are actually defined in
schema document B. And the Dutch schema I've been working on today
(http://standaarden.overheid.nl/vac/1.1/xsd/vac.xsd) certainly takes
advantage of that freedom.
>
> > And it doesn't appear to have anything to say about
> chameleon include.
>
> ... I think this probably means that I would have to augment my
> list of schema document abstraction to actually make it a
> list of (schemadoc, targetNamespace) pairs,
That's precisely what I do in my implementation.
Regards,
Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay
Received on Friday, 16 October 2009 21:22:41 GMT
]]>RE: Escalation mechanism for different interpretation of W3C XML-Schema specification ? http://xsd.stylusstudio.com/2009Oct/post03003.htm2009-10-16T21:11:58Z> While my
> ACSOOD proposal remains very incomplete and has a variety of
> problems, I think it does more or less signal my thinking
> about questions like this [1].
>
Yes. It's close the the way I think about it. It appears to handle a chain
of redefinition (A redefines B, B redefines C) in the same way as I do. It's
not clear what answers it gives for more complex redefinition graphs.
And it doesn't appear to have anything to say about chameleon include.
Regards,
Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay
Received on Friday, 16 October 2009 20:12:32 GMT
]]>RE: Escalation mechanism for different interpretation of W3C XML-Schema specification ? http://xsd.stylusstudio.com/2009Oct/post06003.htm2009-10-16T17:57:20ZMichael Kay writes:
> Perhaps you just let it be caught by the general ban on duplicate
> components.
That was the idea.
> But unless you're careful about the wording, that ban also
> catches you out on a linear chain of redefinitions.
I'm pretty sure that's handled OK. Specifically, the text that says:
"Check for duplicate names (I.e. two or more definitions among the union
of components and prototype components of the same global name in the same
symbol set) and reflect a violation of the appropriate constraint if
found. Note that redeclaration-prototypes need not be checked for
duplicates, as each necessarily redefines a similarly named
prototype-component. "
At this stage of the processing, the redeclarations are all tracked in a
set of redeclaration-prototypes, which is not set that's being checked for
duplicate names in the same symbol space. Once this check for duplicates
is passed, then the redefinitions are processed.
> If there's a cycle in the graph of schema documents then
> there's potential (but not the necessity) of a cycle at the
> level of components. A cycle at the
> component level is clearly a nonsense, and my inclination is
> that the same is true at the document level.
I think I had convinced myself that there could not be a cycle at the
document level, but I'm not remembering why I came to that conclusion.
Certainly the set-of-named-documents approach ACSOOD takes to includes and
imports means that cycles aren't treated as a problem, but are handled. If
A.xsd and B.xsd mutually include each other, then each is added to the set
once (it's a set, so there's no other option) and processed.
As to redefine, if A.xsd redefines T in B.xsd, and B.xsd redefines T in
A.xsd, then I THINK the same text you newly discovered forces an error.
There MUST be an explicit top level declaration for T in both A.xsd and
B.xsd, or the clause you cite triggers failure. If there are explicit top
level declarations, then the ACSOOD "check for duplicate names" clause
quoted above triggers a different error. So, I think redefine cycles are
ruled out by ACSOOD, and probably by most reasonable readings of the text
you discovered.
> That's precisely what I do in my implementation.
Well, I have the general sense that ACSOOD and your implementation are
very much the same in spirit, if not in every detail. I suppose that's
promising in some way or other, but I'm not clear on how it helps us move
ahead this point. At the very least, it's somewhat gratifying to me
personally.
--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------
"Michael Kay" <mike@saxonica.com>
10/16/2009 05:22 PM
To: <noah_mendelsohn@us.ibm.com>
cc: "'Henry S. Thompson'" <ht@inf.ed.ac.uk>, "'XMLSchema at
XML4Pharma'" <XMLSchema@XML4Pharma.com>, <xmlschema-dev@w3.org>
Subject: RE: Escalation mechanism for different
interpretation of W3C XML-Schema specification ?
> -----Original Message-----
> From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com]
> Sent: 16 October 2009 21:35
> To: Michael Kay
> Cc: 'Henry S. Thompson'; 'XMLSchema at XML4Pharma';
> xmlschema-dev@w3.org
> Subject: RE: Escalation mechanism for different
> interpretation of W3C XML-Schema specification ?
>
> Michal Kay writes;
>
> > It's not clear what answers it gives for more complex redefinition
> > graphs.
>
> Well, it's been a long time since I've looked at it. I guess
> I assume that all redefinition graphs are in fact trees, I.e.
> each redefine can redefine only one thing
Well, there's a graph of schema documents, and a graph of components. If
there's a cycle in the graph of schema documents then there's potential
(but
not the necessity) of a cycle at the level of components. A cycle at the
component level is clearly a nonsense, and my inclination is that the same
is true at the document level.
Even without cycles, though, it's not clear to me how ACSOOD handles:
A includes B
A includes C
B redefines X defining a restriction of type T
C redefines X defining a (different) restriction of type T
Perhaps you just let it be caught by the general ban on duplicate
components. But unless you're careful about the wording, that ban also
catches you out on a linear chain of redefinitions.
I noted the statement in your proposal: "Note that the information needed
to
determine a redeclaration prototype is easily determined from the
<redefine>ing XML schema document; the text of a redeclaration always
explicitly refers to the particular schema document containing
(specification of) the component being redefined. " I was surprised to see
this, but I now see that the spec does say (in Schema Representation
Constraint: Individual Component Redefinition) "In all cases there must be
a
top-level definition item of the appropriate name and kind in the
<redefine>d schema document." I now realise I haven't been enforcing that
rule: I only require it to be present in "the schema corresponding to" the
<redefine>d schema document. If A includes B, and R redefines A, then I
allow R to contain redefinitions of components that are actually defined
in
schema document B. And the Dutch schema I've been working on today
(http://standaarden.overheid.nl/vac/1.1/xsd/vac.xsd) certainly takes
advantage of that freedom.
>
> > And it doesn't appear to have anything to say about
> chameleon include.
>
> ... I think this probably means that I would have to augment my
> list of schema document abstraction to actually make it a
> list of (schemadoc, targetNamespace) pairs,
That's precisely what I do in my implementation.
Regards,
Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay
Received on Friday, 16 October 2009 21:58:03 GMT
]]>RE: Escalation mechanism for different interpretation of W3C XML-Schema specification ? http://xsd.stylusstudio.com/2009Oct/post04003.htm2009-10-16T16:35:06ZMichal Kay writes;
> It's not clear what answers it gives for more complex
> redefinition graphs.
Well, it's been a long time since I've looked at it. I guess I assume
that all redefinition graphs are in fact trees, I.e. each redefine can
redefine only one thing, and ultimately there is a path back up to the
collection of the coponents you would have had if no redefinitions at all
were done. What I believe ACSOOD tries to do is, first collect all of the
prototype components that are not themselves the result of redefines, then
apply the redefinitions recursively, with each one being pervasive. Is
there a particular sample you have in mind for which ACSOOD doesn't signal
a fairly clear direction? You may well be right, but I'd be very curious
to learn what it is.
> And it doesn't appear to have anything to say about chameleon include.
I went back and looked at it. You're right that it isn't dealt with
explicitly. My suggestion would be that it be handled locally to the
preparation of prototype components of each include step. Thus, if a
schema with target namespace N included a schema doc with no explicit
target NS, it would for ACSOOD purposes be as if the included document did
have an explicit targetNamespace="N". If that same document were included
in another context, then that would be handled as a completely separate
include, with the same rule applied. I think this probably means that I
would have to augment my list of schema document abstraction to actually
make it a list of (schemadoc, targetNamespace) pairs, where in most cases
the targetNamespace would be determined trivially from the schemadoc's
attribute, but in the case of chameleon would be taken from the include
statement. This would allow the same schemadoc to be included in the list
repeatedly, once for each targetNS.
Again, ACSOOD was an attempt to set down more crisply how I always thought
the whole thing was working right along, though I later came to understand
some of the ambiguities in the spec as written, and that other people have
interpreted it differently. I also am a little unhappy with the fact that
ACSOOD depends in its current form on identify of schema documents (it has
a set of them), which raises some nasty questions about cases in which
schemaLocation URIs differ in, e.g., upper/lowercase, but in ways that we
know won't affect the referent (e.g. http://xxx vs. HTTP://xxx) ACSOOD
more or less winds up treating these as distinct documents, potentially
including them separately, and quite likely resulting in duplicate
component errors. Otherwise, I think it's in the ballpark. Then again, I
said as much in 2004, and it was clear that there were many differing
opinions in the WG as to how things really work in 1.0, how they should
work in 1.1, and especially in how to explain how they should work in 1.1.
I really don't want to reopen all of that here. I'm just pointing to
ACSOOD is a simple way of indicating what my personal assumptions have
been about how redefine should work.
Noah
--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------
"Michael Kay" <mike@saxonica.com>
10/16/2009 04:11 PM
To: <noah_mendelsohn@us.ibm.com>
cc: "'Henry S. Thompson'" <ht@inf.ed.ac.uk>, "'XMLSchema at
XML4Pharma'" <XMLSchema@XML4Pharma.com>, <xmlschema-dev@w3.org>
Subject: RE: Escalation mechanism for different
interpretation of W3C XML-Schema specification ?
> While my
> ACSOOD proposal remains very incomplete and has a variety of
> problems, I think it does more or less signal my thinking
> about questions like this [1].
>
Yes. It's close the the way I think about it. It appears to handle a chain
of redefinition (A redefines B, B redefines C) in the same way as I do.
It's
not clear what answers it gives for more complex redefinition graphs.
And it doesn't appear to have anything to say about chameleon include.
Regards,
Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay
Received on Friday, 16 October 2009 20:35:59 GMT
]]>RE: Escalation mechanism for different interpretation of W3C XML-Schema specification ? http://xsd.stylusstudio.com/2009Oct/post02003.htm2009-10-16T14:59:13ZMichael Kay writes:
> Because the common components have been copied into three different
> namespaces, a redefine occurring in one namespace does not
> affect copies of
> the component in a different namespace. That's Saxon's interpretation,
> anyway. You could take the view that the "pervasiveness" of redefinition
> makes it transcend the renaming done by the chameleon include,
> but I don't.
FWIW, I don't either. More specifically, if you'd asked me not about the
text of the Recommendation as it came out (which I think we've established
is somewhat self-contradictory and thus interpreted differently by
different readers), but about what I thought we were trying to say as we
all wrote that, I agree with you. While my ACSOOD proposal remains very
incomplete and has a variety of problems, I think it does more or less
signal my thinking about questions like this [1].
BTW: this proposal gets referenced from time to time, and as far as I can
tell the only copy remains in member-only space. If there's a way to do
it without inconveniencing the chair or working group members, I will try
to get permission post another public copy, perhaps in the W3C public
archives. I think it's useful for references like this to be public when
practical. (I am not proposing to start active discussion of it now, but
every few years an email thread like this pops up, and I find it
inconvenient to have links that can't be read outside of W3C. I'll ask
on the working group's list, which is the right place to do it. In the
meantime, apologies to readers outside the WG who can't see it. FYI, we
were (in 2004!) making a major effort to clarify the composition story for
XSD 1.1. The paper reference at [1] was an experimental attempt by me to
create a design that would capture what I thought we intended in XSD 1.0.
I think there are some good ideas in it, but it's also incomplete and has
a number of problems. Other important proposals were made by other
working group members, many months were spent trying to extract from all
of this a story that would garner consensus as a better explanation than
the one we had in XSD 1.0, and to a signficant degree we failed. So, I
refer to this only because with respect to issues like the ones Mike
raises, some of my thinking is captured in more detail at [1].
Noah
[1]
http://lists.w3.org/Archives/Member/w3c-xml-schema-ig/2004Jul/att-0004/CompositionArchitecture.html
--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------
"Michael Kay" <mike@saxonica.com>
Sent by: xmlschema-dev-request@w3.org
10/16/2009 09:29 AM
To: "'Henry S. Thompson'" <ht@inf.ed.ac.uk>
cc: "'XMLSchema at XML4Pharma'" <XMLSchema@XML4Pharma.com>,
<xmlschema-dev@w3.org>, (bcc: Noah Mendelsohn/Cambridge/IBM)
Subject: RE: Escalation mechanism for different
interpretation of W3C XML-Schema specification ?
> Hmmm -- let's leave redefine aside, as we've agreed to differ
> on that before, but I'm surprised you recommend against
> chameleon include. I find it hugely useful (for those little
> bits that you use all the time but aren't worth putting in a
> namespace) and am not aware of any interop problems with it. . .
I've been working on a bug report relating to a Dutch government schema
published at
http://standaarden.overheid.nl/vac/1.1/xsd/vac.xsd
which makes extensive use of redefines and chameleon include. I've fixed
the
bug that stopped this working under Saxon 9.2, but I would make some
observations on the schema, which are I think rather pertinent to this
thread.
There's a cluster of three no-namespace schema documents (overheid-types,
overheid-classes, overheid-schemes) that are chameleon-included into three
different namespaces (short names /vac/, /dc/terms/, and /owms/terms/).
The
effect of this is to create three near-identical copies of each of the
components defined in these three schema documents, one in each namespace.
This means that as far as XSLT and XQuery are concerned,
elements/attributes
defined in terms of these types will be unrelated to each other in the
type
hierarchy, which means that writing schema-aware stylesheets and queries
is
likely to be very confusing. This is probably one of the main reasons I'm
not a fan of chameleon include.
But that's not all: the schema also makes heavy use of redefines.
Specifically, if we call this no-namespace cluster COMMON, we have the
structure (slightly simplified to capture the essence):
Namespace /vac/
vac.xsd includes COMMON
vac.xsd imports owms-classes-redef.xsd
vac.xsd imports overheid-classes-redef.xsd
Namespace /dc/terms/
owms-classes-redef.xsd redefines dcterms-elem.xsd
dcterms-elem.xsd includes COMMON
Namespace /owms/terms/
overheid-classes-redef.xsd redefines owns.xsd
owms.xsd includes COMMON
owms.xsd imports dcterms-elem.xsd
Note that dcterms-elem.xsd is reachable from vac.xsd via one route that
contain a "redefines" step, and by another route that omits this step (but
which does contain a different redefines step). This is where the
interpretation of "pervasiveness" is critical: Saxon takes the view that
all
references to components that have been redefined are references to the
post-redefinition component. In fact the rule introduced in Saxon 9.2
(whose
incorrect implementation caused the bug) is that every component has a
redefinition level, so if A redefines B and B redefines C then a given
component may have redefinition levels of 2, 1, and 0; all references to a
component name are taken as references to the highest available
redefinition
level, and if there are two different components at the highest
redefinition
level, it's an error (for example, A redefines C, and B also redefines C).
There's nothing at all in the spec to justify these rules, but it's the
only
way I could find of handling complex redefinition lattices that seemed to
make sense.
But the chameleon includes interfere with this (perhaps deliberately).
Because the common components have been copied into three different
namespaces, a redefine occurring in one namespace does not affect copies
of
the component in a different namespace. That's Saxon's interpretation,
anyway. You could take the view that the "pervasiveness" of redefinition
makes it transcend the renaming done by the chameleon include, but I
don't.
In experimenting further with this schema, I discovered that if the two
imports from vac.xsd are reversed in order, the import of
owms-classes-redef.xsd has no effect, because it is then importing a
namespace that is already known to the processor; Saxon ignores the
schemaLocation URI in this case. So the schema document
owms-classes-redef.xsd, and the redefinitions that it contains, are simply
ignored. This makes the situation very fragile: reversing the order of
imports does not make the processing fail, it just silently compiles a
different schema. I think this reinforces Henry's argument that if you're
going to redefine, then there should be one redefining document for each
namespace, which acts as a gateway to that namespace, and no other
includes/imports/redefines from elsewhere in the schema should bypass this
gateway. This schema breaks this rule, and gets away with it only because
of
gateway document is encountered before the bypassing document.
Michael Kay
Saxonica
Received on Friday, 16 October 2009 19:00:04 GMT
]]>RE: Escalation mechanism for different interpretation of W3C XML-Schema specification ? http://xsd.stylusstudio.com/2009Oct/post01003.htm2009-10-16T14:29:34Z> Hmmm -- let's leave redefine aside, as we've agreed to differ
> on that before, but I'm surprised you recommend against
> chameleon include. I find it hugely useful (for those little
> bits that you use all the time but aren't worth putting in a
> namespace) and am not aware of any interop problems with it. . .
I've been working on a bug report relating to a Dutch government schema
published at
http://standaarden.overheid.nl/vac/1.1/xsd/vac.xsd
which makes extensive use of redefines and chameleon include. I've fixed the
bug that stopped this working under Saxon 9.2, but I would make some
observations on the schema, which are I think rather pertinent to this
thread.
There's a cluster of three no-namespace schema documents (overheid-types,
overheid-classes, overheid-schemes) that are chameleon-included into three
different namespaces (short names /vac/, /dc/terms/, and /owms/terms/). The
effect of this is to create three near-identical copies of each of the
components defined in these three schema documents, one in each namespace.
This means that as far as XSLT and XQuery are concerned, elements/attributes
defined in terms of these types will be unrelated to each other in the type
hierarchy, which means that writing schema-awarestylesheets and queries is
likely to be very confusing. This is probably one of the main reasons I'm
not a fan of chameleon include.
But that's not all: the schema also makes heavy use of redefines.
Specifically, if we call this no-namespace cluster COMMON, we have the
structure (slightly simplified to capture the essence):
Namespace /vac/
vac.xsd includes COMMON
vac.xsd imports owms-classes-redef.xsd
vac.xsd imports overheid-classes-redef.xsd
Namespace /dc/terms/
owms-classes-redef.xsd redefines dcterms-elem.xsd
dcterms-elem.xsd includes COMMON
Namespace /owms/terms/
overheid-classes-redef.xsd redefines owns.xsd
owms.xsd includes COMMON
owms.xsd imports dcterms-elem.xsd
Note that dcterms-elem.xsd is reachable from vac.xsd via one route that
contain a "redefines" step, and by another route that omits this step (but
which does contain a different redefines step). This is where the
interpretation of "pervasiveness" is critical: Saxon takes the view that all
references to components that have been redefined are references to the
post-redefinition component. In fact the rule introduced in Saxon 9.2 (whose
incorrect implementation caused the bug) is that every component has a
redefinition level, so if A redefines B and B redefines C then a given
component may have redefinition levels of 2, 1, and 0; all references to a
component name are taken as references to the highest available redefinition
level, and if there are two different components at the highest redefinition
level, it's an error (for example, A redefines C, and B also redefines C).
There's nothing at all in the spec to justify these rules, but it's the only
way I could find of handling complex redefinition lattices that seemed to
make sense.
But the chameleon includes interfere with this (perhaps deliberately).
Because the common components have been copied into three different
namespaces, a redefine occurring in one namespace does not affect copies of
the component in a different namespace. That's Saxon's interpretation,
anyway. You could take the view that the "pervasiveness" of redefinition
makes it transcend the renaming done by the chameleon include, but I don't.
In experimenting further with this schema, I discovered that if the two
imports from vac.xsd are reversed in order, the import of
owms-classes-redef.xsd has no effect, because it is then importing a
namespace that is already known to the processor; Saxon ignores the
schemaLocation URI in this case. So the schema document
owms-classes-redef.xsd, and the redefinitions that it contains, are simply
ignored. This makes the situation very fragile: reversing the order of
imports does not make the processing fail, it just silently compiles a
different schema. I think this reinforces Henry's argument that if you're
going to redefine, then there should be one redefining document for each
namespace, which acts as a gateway to that namespace, and no other
includes/imports/redefines from elsewhere in the schema should bypass this
gateway. This schema breaks this rule, and gets away with it only because of
gateway document is encountered before the bypassing document.
Michael Kay
Saxonica
Received on Friday, 16 October 2009 13:30:19 GMT
]]>RE: Escalation mechanism for different interpretation of W3C XML-Schema specification ? http://xsd.stylusstudio.com/2009Oct/post09002.htm2009-10-12T21:04:47Z> Hmmm -- let's leave redefine aside, as we've agreed to differ
> on that before, but I'm surprised you recommend against
> chameleon include. I find it hugely useful (for those little
> bits that you use all the time but aren't worth putting in a
> namespace) and am not aware of any interop problems with it. . .
Well, it's partly that if you allow the same data to be in different
namespaces at different times then it's much harder to write reusable code
in XSLT/XQuery etc that works regardless of which namespace has been chosen
today.
But it certainly can lead to problems of interpretation:
(a) problems hinging on the (XSD 1.0) phrase "corresponds to a <schema>
element information item in a well-formed information set, which in turn
corresponds to a valid schema." - the correspondence of the schema
information item to the valid schema is never spelt out, so it's not clear
for example if A does a chameleon include on B which imports C which imports
the no-namespace schema document D, whether components defined in D are
moved into the target namespace of A; especially if C or D are also
reachable by other routes.
(b) problems hinging on exactly where the substitution of targetNamespace
applies, for example, whether it affects XPath expressions in identity
constraints, QNames used in enumeration facets, or references to
no-namespace components defined in a schema document that is not itself
within the scope of the chameleon include.
We've improved the rules for XSD 1.1, but it's still a facility I would be
inclined to avoid.
Regards,
Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay
Received on Monday, 12 October 2009 20:05:28 GMT
]]>Re: Escalation mechanism for different interpretation of W3C XML-Schema specification ? http://xsd.stylusstudio.com/2009Oct/post08002.htm2009-10-12T20:38:15Z-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Michael Kay writes:
> I suspect, but without testing(!) that the strategy can be extended to
> xs:redefine as follows:
>
> (a) if redefinition for a namespace is required, create a new schema
> document with that targetNamespace that invokes the (previous) primary
> schema document for that namespace using xs:redefine, and contains all the
> redefinitions needed.
>
> (b) change the driver document to refer to the redefinition documents
> introduced in step (1) in place of the (previous) primary shcema documents.
Yes, that sounds right.
> A similar approach might also work reliably for "chameleon include".
Includes in general are less problematic, as there is no option for
processors -- they _must_ process the nominated schema document.
> But better advice is not to use redefine or chameleon include.
Hmmm -- let's leave redefine aside, as we've agreed to differ on that
before, but I'm surprised you recommend against chameleon include. I
find it hugely useful (for those little bits that you use all the time
but aren't worth putting in a namespace) and am not aware of any
interop problems with it. . .
ht
- --
Henry S. Thompson, School of Informatics, University of Edinburgh
Half-time member of W3C Team
10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 651-1426, 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]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFK04WokjnJixAXWBoRAsvbAJ9nerp4yckxN4iPts1pBBDyZvyalgCaAzfm
mGqLLD1JN8IMkIsAynGy96k=
=Ot+l
-----END PGP SIGNATURE-----
Received on Monday, 12 October 2009 19:38:48 GMT
]]>Re: [XML Schema 1.1] Two ways to create interleaved, any-order content ... are they identical? http://xsd.stylusstudio.com/2009Oct/post00003.htm2009-10-12T18:02:10Z
On 12 Oct 2009, at 11:00 , Costello, Roger L. wrote:
>
> Hi Folks,
>
> Below are two ways to declare a <Book> element.
>
> Both versions use <all>, to permit the elements within <Book> to
> occur in any order.
>
> The first version uses an unbounded <any>. The second version uses
> interleaved open content.
>
> Are these two versions identical?
You may mean "Do they accept the same inputs as valid instances
of element Book?" Yes, I think they do.
> If so, is there an advantage of one over the other?
Some people may find one formulation clearer or simpler than the
other; they will rightly prefer the one they find clearer. I
expect different people will have different preferences, depending
on their tastes.
If a schema is designed so that ever complex type, or most of them,
has a particular form of open content, then the open content can
be defaulted at the schema document level, which will make most
content models shorter and simpler. Readers who forget that the
schema document supplies default open content may be surprised and
complain about action at a distance.
In the case of all-groups, using an explicit wildcard and using
interleave open content are roughly similar in complexity of the
declaration. In other cases, explicit wildcards are much more
verbose and for many schema authors rather error-prone. See
http://www.w3.org/TR/xmlschema-guide2versioning/ for examples.
> If they are not identical, how do they differ?
You may mean "Do they produce indistinguishable PSVIs?"
No, not quite; the [match information] property in the PSVI allows
the two to be distinguished, for elements other than Author, Title,
Date, ISBN, and Publisher: in the one case, those elements will have
[match information] = 'lax' (since they match a lax wildcard in the
content model), and in the other they will have [match information]
= 'open' (since they match open content). This allows the
downstream application to distinguish the two cases, if it wishes to.
In the usual case, making downstream processing depend on such a subtle
distinction is probably not a good idea, but YMMV and there may be
special circumstances. Certainly there are some designers who
like the idea of being able to say that if an element in the input
matches an element in the version N content model, then a
version N processor is obligated to process it in a certain
way, and if the element in the input matches a wildcard (or:
matches only open content) in the version N content model, then
a version N processor is obligated to tolerate it, or to ignore
it, or to handle it in some other way. In such a design,
"matches an element" and "matches a wildcard" are syntax-level
signals for different kinds of processing. The signal "matches
an open-content wildcard" can fit nicely into this pattern,
either to signal a third kind of processing or to shift the
distinction from element-vs-wildcard to content-model-vs-opencontent.
HTH
--
****************************************************************
* C. M. Sperberg-McQueen, Black Mesa Technologies LLC
* http://www.blackmesatech.com
* http://cmsmcq.com/mib
* http://balisage.net
****************************************************************
Received on Tuesday, 13 October 2009 00:02:41 GMT
]]>RE: Escalation mechanism for different interpretation of W3C XML-Schema specification ? http://xsd.stylusstudio.com/2009Oct/post06002.htm2009-10-12T17:48:09Z
I agree with all of this, but it leaves the question of xs:redefine.
I suspect, but without testing(!) that the strategy can be extended to
xs:redefine as follows:
(a) if redefinition for a namespace is required, create a new schema
document with that targetNamespace that invokes the (previous) primary
schema document for that namespace using xs:redefine, and contains all the
redefinitions needed.
(b) change the driver document to refer to the redefinition documents
introduced in step (1) in place of the (previous) primary shcema documents.
A similar approach might also work reliably for "chameleon include".
But better advice is not to use redefine or chameleon include.
Regards,
Michael Kay
http://www.saxonica.com/
http://twitter.com/michaelhkay
> -----Original Message-----
> From: xmlschema-dev-request@w3.org
> [mailto:xmlschema-dev-request@w3.org] On Behalf Of Henry S. Thompson
> Sent: 12 October 2009 16:40
> To: XMLSchema at XML4Pharma
> Cc: xmlschema-dev@w3.org
> Subject: Re: Escalation mechanism for different
> interpretation of W3C XML-Schema specification ?
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Stimulated in equal measure by this thread, and a request
> from the XML Security WG [0], I came up with my personal
> 'best practice' guideline for schema document design for
> multi-namespace schemas. I include the core bit below -- for
> the full context and a worked example, see my reply to the
> DSIG WG [1].
>
> ht
>
> [0]
> http://lists.w3.org/Archives/Public/public-xmlsec/2009Oct/0019.html
> [1]
> http://lists.w3.org/Archives/Public/public-xmlsec/2009Oct/0023.html
> - -------------------------
> HST's best practice guide for multiple-namespace schema composition
>
> It's helpful in discussions of this sort to be careful with
> vocabulary:
>
> Schema document: An XML document in the W3C XML Schema namespace
> Schema: An abstract data object, typically composed from one or more
> schema documents according to the rules given in the W3C XML
> Schema specs.
>
> A schema document specifies either one or no target namespace.
>
> A schema may well contain element & attribute declarations
> and/or type definitions for many target namespaces.
>
> The W3C XML Schema specs provide a number of mechanisms for
> assembling the schema documents needed to construct a schema
> for a particular validation episode:
>
> 1) the schemaLocation attribute on xs:include elements.
> 2) xsi:schemaLocation (in the instance to be validated);
> 3) the schemaLocation attribute on xs:import elements;
> 4) the namespace URIs themselves (in the instance to be validated, or
> from the namespace attribute on xs:import elements);
>
> Without going into the details of what's optional and what's
> required, or of the range of choices implementations exhibit,
> here's my recommendation for multi-namespace schemas:
>
> 1) For each namespace in your language, there should be one primary
> schema document. It may be the only schema document for that
> namespace, or it may use xs:include (which must have a
> schemaLocation attribute) to allow for modular development by
> including multiple as-it-were secondary schema documents;
>
> 2) Whenever reference is made to names in another namespace from a
> primary or secondary schema document, use an xs:import _without_ a
> schemaLocation attribute;
>
> 3) Create a driver schema document, whose target namespace is the
> namespace of the (most common) document element of instance
> documents in the language. It should contain an xs:include of the
> primary schema document for that namespace, and xs:imports for all
> the other namespaces, _with_ schemaLocation attributes pointing to
> the primary schema documents for those other namespaces.
>
> Then, by passing the location of the driver schema document
> to schema validation tools and/or by including an
> xsi:schemaLocation attribute on the document element of
> instances to be validated which associates the target
> namespace of the driver schema document with its location,
> you will get the behaviour you need from all the
> tools/implementations I am aware of.
>
> Schematically, this looks like
>
> driver.xsd -- TNS = http://www.example.org/rootNS
> /|\
> / | \
> / | \
> / | \
> xs:include | \
> schemaLoc= | \
> / | \
> / xs:import \
> / NS=...NS2 \
> / schemaLoc= \
> / | xs:import
> / | NS=...NS3
> / | schemaLoc=
> / | \
> primary1.xsd primary2.xsd primary3.xsd
> TNS=...rootNS TNS=...NS2 TNS=...NS3
> / \ /|\
> / \ / | \
> / \ / | \
> / \ / | \
> xs:import xs:import / | \
> NS=...NS2 NS=...NS3 xs:include | \
> schemaLoc= | \
> / | \
> 3.1.xsd | \
> xs:include \
> schemaLoc= \
> | \
> 3.2.xsd \
> xs:include
> schemaLoc=
> |
> 3.3.xsd
>
> - --
> Henry S. Thompson, School of Informatics, University
> of Edinburgh
> Half-time member of W3C Team
> 10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44)
> 131 650-4440
> Fax: (44) 131 651-1426, 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] -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.6 (GNU/Linux)
>
> iD8DBQFK0021kjnJixAXWBoRAmPMAJ9dLLKZsj+r2y/tUtIsJ/wAjuL0kQCfWwzT
> LqnqG7FgzH5zwP3XMIrNsb4=
> =vK80
> -----END PGP SIGNATURE-----
>
Received on Monday, 12 October 2009 16:48:52 GMT
]]>Re: Escalation mechanism for different interpretation of W3C XML-Schema specification ? http://xsd.stylusstudio.com/2009Oct/post05002.htm2009-10-12T16:39:33Z-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Stimulated in equal measure by this thread, and a request from the XML
Security WG [0], I came up with my personal 'best practice' guideline
for schema documentdesign for multi-namespace schemas. I include the
core bit below -- for the full context and a worked example, see my
reply to the DSIG WG [1].
ht
[0] http://lists.w3.org/Archives/Public/public-xmlsec/2009Oct/0019.html
[1] http://lists.w3.org/Archives/Public/public-xmlsec/2009Oct/0023.html
- -------------------------
HST's best practice guide for multiple-namespace schema composition
It's helpful in discussions of this sort to be careful with
vocabulary:
Schema document: An XML document in the W3C XML Schema namespace
Schema: An abstract data object, typically composed from one or more
schema documents according to the rules given in the W3C XML
Schema specs.
A schema document specifies either one or no target namespace.
A schema may well contain element & attribute declarations and/or type
definitions for many target namespaces.
The W3C XML Schema specs provide a number of mechanisms for assembling
the schema documents needed to construct a schema for a particular
validation episode:
1) the schemaLocation attribute on xs:include elements.
2) xsi:schemaLocation (in the instance to be validated);
3) the schemaLocation attribute on xs:import elements;
4) the namespace URIs themselves (in the instance to be validated, or
from the namespace attribute on xs:import elements);
Without going into the details of what's optional and what's required,
or of the range of choices implementations exhibit, here's my
recommendation for multi-namespace schemas:
1) For each namespace in your language, there should be one primary
schema document. It may be the only schema document for that
namespace, or it may use xs:include (which must have a
schemaLocation attribute) to allow for modular development by
including multiple as-it-were secondary schema documents;
2) Whenever reference is made to names in another namespace from a
primary or secondary schema document, use an xs:import _without_ a
schemaLocation attribute;
3) Create a driver schema document, whose target namespace is the
namespace of the (most common) document element of instance
documents in the language. It should contain an xs:include of the
primary schema document for that namespace, and xs:imports for all
the other namespaces, _with_ schemaLocation attributes pointing to
the primary schema documents for those other namespaces.
Then, by passing the location of the driver schema document to schema
validationtools and/or by including an xsi:schemaLocation attribute
on the document element of instances to be validated which associates
the target namespace of the driver schema document with its location,
you will get the behaviour you need from all the tools/implementations
I am aware of.
Schematically, this looks like
driver.xsd -- TNS = http://www.example.org/rootNS
/|\
/ | \
/ | \
/ | \
xs:include | \
schemaLoc= | \
/ | \
/ xs:import \
/ NS=...NS2 \
/ schemaLoc= \
/ | xs:import
/ | NS=...NS3
/ | schemaLoc=
/ | \
primary1.xsd primary2.xsd primary3.xsd
TNS=...rootNS TNS=...NS2 TNS=...NS3
/ \ /|\
/ \ / | \
/ \ / | \
/ \ / | \
xs:import xs:import / | \
NS=...NS2 NS=...NS3 xs:include | \
schemaLoc= | \
/ | \
3.1.xsd | \
xs:include \
schemaLoc= \
| \
3.2.xsd \
xs:include
schemaLoc=
|
3.3.xsd
- --
Henry S. Thompson, School of Informatics, University of Edinburgh
Half-time member of W3C Team
10 Crichton Street, Edinburgh EH8 9AB, SCOTLAND -- (44) 131 650-4440
Fax: (44) 131 651-1426, 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]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFK0021kjnJixAXWBoRAmPMAJ9dLLKZsj+r2y/tUtIsJ/wAjuL0kQCfWwzT
LqnqG7FgzH5zwP3XMIrNsb4=
=vK80
-----END PGP SIGNATURE-----
Received on Monday, 12 October 2009 15:40:18 GMT
]]>[XML Schema 1.1] Two ways to create interleaved, any-order content ... are they identical? http://xsd.stylusstudio.com/2009Oct/post07002.htm2009-10-12T13:00:39Z
Hi Folks,
Below are two ways to declare a <Book> element.
Both versions use <all>, to permit the elements within <Book> to occur in any order.
The first version uses an unbounded <any>. The second version uses interleaved open content.
Are these two versions identical? If so, is there an advantage of one over the other? If they are not identical, how do they differ?
/Roger
VERSION #1
<xs:element name="Book">
<xs:complexType>
<xs:all>
<xs:any maxOccurs="unbounded" />
<xs:element name="Author" type="xs:string" />
<xs:element name="Title" type="xs:string" />
<xs:element name="Date" type="xs:string" />
<xs:element name="ISBN" type="xs:string"/>
<xs:element name="Publisher" type="xs:string" />
</xs:all>
</xs:complexType>
</xs:element>
VERSION #2
<xs:element name="Book">
<xs:complexType>
<xs:openContent mode="interleave">
<xs:any />
</xs:openContent>
<xs:all>
<xs:element name="Title" type="xs:string"/>
<xs:element name="Author" type="xs:string" />
<xs:element name="Date" type="xs:string"/>
<xs:element name="ISBN" type="xs:string"/>
<xs:element name="Publisher" type="xs:string"/>
</xs:all>
</xs:complexType>
</xs:element>
Received on Monday, 12 October 2009 17:01:11 GMT
]]>RE: xsd ambigious http://xsd.stylusstudio.com/2009Oct/post04002.htm2009-10-09T11:05:50ZHi Pete,
Good point. That sounds like a good idea.
Cheers for that,
Andy
-----Original Message-----
From: xmlschema-dev-request@w3.org [mailto:xmlschema-dev-request@w3.org] On Behalf Of Pete Cordell
Sent: 09 October 2009 10:03
To: Neill, Andrew
Cc: xmlschema-dev@w3.org
Subject: Re: xsd ambigious
Hi Andy,
In that case it might be more aesthetic to move the minOccurs to the outer
xsd:choice so you get:
<xsd:choice minOccurs="0" maxOccurs="unbounded">
Pete.
----- Original Message -----
From: "Neill, Andrew" <andy.neill@siemens.com>
To: "Pete Cordell" <petexmldev@codalogic.com>
Cc: <xmlschema-dev@w3.org>
Sent: Friday, October 09, 2009 9:35 AM
Subject: RE: xsd ambigious
Hi Pete,
Thanks for that but I thought about it and although I wanted d to appear
before e or f, it is possible to submit an xml file with none of these
fields populated so I left it in there.
Cheers,
Andy
-----Original Message-----
From: Pete Cordell [mailto:petexmldev@codalogic.com]
Sent: 09 October 2009 09:33
To: Neill, Andrew
Cc: xmlschema-dev@w3.org
Subject: Re: xsd ambigious
Hi Andy,
That's great. Actually, I don't know whether you noticed already, but
looking at it again, I don't think the minOccurs="0" on the xsd:sequence is
required.
HTH,
Pete.
----- Original Message -----
From: "Neill, Andrew" <andy.neill@siemens.com>
To: "Pete Cordell" <petexmldev@codalogic.com>; <xmlschema-dev@w3.org>
Sent: Thursday, October 08, 2009 11:11 AM
Subject: RE: xsd ambigious
Hi Pete,
That works. I don't know how I missed that.
Many Thanks,
Andy
-----Original Message-----
From: Pete Cordell [mailto:petexmldev@codalogic.com]
Sent: 08 October 2009 11:07
To: Neill, Andrew; xmlschema-dev@w3.org
Subject: Re: xsd ambigious
Hi Andy,
Does something like the following work?
...
<xsd:choice maxOccurs="unbounded">
<xsd:element ref="a" minOccurs="0"/>
<xsd:element ref="b" minOccurs="0"/>
<xsd:element ref="c" minOccurs="0"/>
<xsd:sequence minOccurs="0">
<xsd:element ref="d"/>
<xsd:choice>
<xsd:sequence>
<xsd:element ref="e"/>
<xsd:element ref="f" minOccurs="0"/>
</xsd:sequence>
<xsd:element ref="f"/>
</xsd:choice>
</xsd:sequence>
...
HTH,
Pete.
--
=============================================
Pete Cordell
Codalogic Ltd
Interface XML to C++ the easy way using XML C++
data binding to convert XSD schemas to C++ classes.
Visit http://codalogic.com/lmx/ or http://www.xml2cpp.com
for more info
=============================================
----- Original Message -----
From: "Neill, Andrew" <andy.neill@siemens.com>
To: <xmlschema-dev@w3.org>
Sent: Wednesday, October 07, 2009 5:10 PM
Subject: xsd ambigious
Can anyone help with this XSD please? It doesnt seem to work?
Essentially i want to ensure that if "E" or "F" are populated then "D" is
populated before them. The rest of the elements can appear in any order and
any amount of times.
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="element">
<xsd:complexType>
<xsd:choice maxOccurs="unbounded">
<xsd:element ref="a" minOccurs="0"/>
<xsd:element ref="b" minOccurs="0"/>
<xsd:element ref="c" minOccurs="0"/>
<xsd:sequence>
<xsd:element ref="d"/>
<xsd:element ref="e"/>
</xsd:sequence>
<xsd:sequence>
<xsd:element ref="d"/>
<xsd:element ref="f"/>
</xsd:sequence>
</xsd:choice>
</xsd:complexType>
</xsd:element>
<xsd:element name="a"/>
<xsd:element name="b"/>
<xsd:element name="c"/>
<xsd:element name="d"/>
<xsd:element name="e"/>
<xsd:element name="f"/>
</xsd:schema>
Many Thanks,
Andy
Received on Friday, 9 October 2009 09:07:13 GMT
]]>RE: xsd ambigious http://xsd.stylusstudio.com/2009Oct/post02002.htm2009-10-09T10:35:50ZHi Pete,
Thanks for that but I thought about it and although I wanted d to appear before e or f, it is possible to submit an xml file with none of these fields populated so I left it in there.
Cheers,
Andy
-----Original Message-----
From: Pete Cordell [mailto:petexmldev@codalogic.com]
Sent: 09 October 2009 09:33
To: Neill, Andrew
Cc: xmlschema-dev@w3.org
Subject: Re: xsd ambigious
Hi Andy,
That's great. Actually, I don't know whether you noticed already, but
looking at it again, I don't think the minOccurs="0" on the xsd:sequence is
required.
HTH,
Pete.
----- Original Message -----
From: "Neill, Andrew" <andy.neill@siemens.com>
To: "Pete Cordell" <petexmldev@codalogic.com>; <xmlschema-dev@w3.org>
Sent: Thursday, October 08, 2009 11:11 AM
Subject: RE: xsd ambigious
Hi Pete,
That works. I don't know how I missed that.
Many Thanks,
Andy
-----Original Message-----
From: Pete Cordell [mailto:petexmldev@codalogic.com]
Sent: 08 October 2009 11:07
To: Neill, Andrew; xmlschema-dev@w3.org
Subject: Re: xsd ambigious
Hi Andy,
Does something like the following work?
...
<xsd:choice maxOccurs="unbounded">
<xsd:element ref="a" minOccurs="0"/>
<xsd:element ref="b" minOccurs="0"/>
<xsd:element ref="c" minOccurs="0"/>
<xsd:sequence minOccurs="0">
<xsd:element ref="d"/>
<xsd:choice>
<xsd:sequence>
<xsd:element ref="e"/>
<xsd:element ref="f" minOccurs="0"/>
</xsd:sequence>
<xsd:element ref="f"/>
</xsd:choice>
</xsd:sequence>
...
HTH,
Pete.
--
=============================================
Pete Cordell
Codalogic Ltd
Interface XML to C++ the easy way using XML C++
data binding to convert XSD schemas to C++ classes.
Visit http://codalogic.com/lmx/ or http://www.xml2cpp.com
for more info
=============================================
----- Original Message -----
From: "Neill, Andrew" <andy.neill@siemens.com>
To: <xmlschema-dev@w3.org>
Sent: Wednesday, October 07, 2009 5:10 PM
Subject: xsd ambigious
Can anyone help with this XSD please? It doesnt seem to work?
Essentially i want to ensure that if "E" or "F" are populated then "D" is
populated before them. The rest of the elements can appear in any order and
any amount of times.
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:element name="element">
<xsd:complexType>
<xsd:choice maxOccurs="unbounded">
<xsd:element ref="a" minOccurs="0"/>
<xsd:element ref="b" minOccurs="0"/>
<xsd:element ref="c" minOccurs="0"/>
<xsd:sequence>
<xsd:element ref="d"/>
<xsd:element ref="e"/>
</xsd:sequence>
<xsd:sequence>
<xsd:element ref="d"/>
<xsd:element ref="f"/>
</xsd:sequence>
</xsd:choice>
</xsd:complexType>
</xsd:element>
<xsd:element name="a"/>
<xsd:element name="b"/>
<xsd:element name="c"/>
<xsd:element name="d"/>
<xsd:element name="e"/>
<xsd:element name="f"/>
</xsd:schema>
Many Thanks,
Andy
Received on Friday, 9 October 2009 08:36:28 GMT
]]>Re: xsd ambigious http://xsd.stylusstudio.com/2009Oct/post03002.htm2009-10-09T10:02:46ZHi Andy,
In that case it might be more aesthetic to move the minOccurs to the outer
xsd:choice so you get:
<xsd:choice minOccurs="0" maxOccurs="unbounded">
Pete.
----- Original Message -----
From: "Neill, Andrew" <andy.neill@siemens.com>
To: "Pete Cordell" <petexmldev@codalogic.com>
Cc: <xmlschema-dev@w3.org>
Sent: Friday, October 09, 2009 9:35 AM
Subject: RE: xsd ambigious
Hi Pete,
Thanks for that but I thought about it and although I wanted d to appear
before e or f, it is possible to submit an xml file with none of these
fields populated so I left it in there.
Cheers,
Andy
-----Original Message-----
From: Pete Cordell [mailto:petexmldev@codalogic.com]
Sent: 09 October 2009 09:33
To: Neill, Andrew
Cc: xmlschema-dev@w3.org
Subject: Re: xsd ambigious
Hi Andy,
That's great. Actually, I don't know whether you noticed already, but
looking at it again, I don't think the minOccurs="0" on the xsd:sequence is
required.
HTH,
Pete.
----- Original Message -----
From: "Neill, Andrew" <andy.neill@siemens.com>
To: "Pete Cordell" <petexmldev@codalogic.com>; <xmlschema-dev@w3.org>
Sent: Thursday, October 08, 2009 11:11 AM
Subject: RE: xsd ambigious
Hi Pete,
That works. I don't know how I missed that.
Many Thanks,
Andy
-----Original Message-----
From: Pete Cordell [mailto:petexmldev@codalogic.com]
Sent: 08 October 2009 11:07
To: Neill, Andrew; xmlschema-dev@w3.org
Subject: Re: xsd ambigious
Hi Andy,
Does something like the following work?
...
<xsd:choice maxOccurs="unbounded">
<xsd:element ref="a" minOccurs="0"/>
<xsd:element ref="b" minOccurs="0"/>
<xsd:element ref="c" minOccurs="0"/>
<xsd:sequence minOccurs="0">
<xsd:element ref="d"/>
<xsd:choice>
<xsd:sequence>
<xsd:element ref="e"/>
<xsd:element ref="f" minOccurs="0"/>
</xsd:sequence>
<xsd:element ref="f"/>
</xsd:choice>
</xsd:sequence>
...
HTH,
Pete.
--
=============================================
Pete Cordell
Codalogic Ltd
Interface XML to C++ the easy way using XML C++
data binding to convert XSD schemas to C++ classes.
Visit http://codalogic.com/lmx/ or http://www.xml2cpp.com
for more info
=============================================
----- Original Message -----
From: "Neill, Andrew" <andy.neill@siemens.com>
To: <xmlschema-dev@w3.org>
Sent: Wednesday, Octo