OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [emergency] Schema Test Results



I found a reference in "XML Schemas", WROX that may help:

Under Element Declarations:

"A type definition can be anonymous, and nested inside the element declaration..."

"A type can be referred to, by putting the name of the type as the value of a type attribute, as we have been doing with the value string."

So it would appear that simpletype declarations inside the element declaration must be anonymous (i.e. not named). Simpletype definitions not nested inside an element declaration must be named and the names must be unique (as previously discussed).

gary

-----Original Message-----
From: R. Allen Wyke [mailto:emergency-tc@earthlink.net]
Sent: Saturday, July 31, 2004 10:22 AM
To: Kon Wilms
Cc: 'Art Botterell'; 'Emergency TC'
Subject: Re: [emergency] Schema Test Results


I have spent some time looking into this as well, and I admit that I am
having trouble finding any kind of definitely answer from the XML
Schema spec. Maybe I am over looking it - not sure. Anyway, I have
included what I have found as well as the remaining questions that, if
we can answer, will resolve these....

On Jul 16, 2004, at 5:55 PM, Kon Wilms wrote:

> Thanks Art,
>
> Using the XSD file from the document, Here's the run-through:
>
> 1. Microsoft .NET DOM and Borland DOM fail on all <simpletype name=nnn>
> fields. Since simpletype is nested within <element name=nnn> it
> inherits
> the name and thus <simpletype name=nnn> should simply read <simpletype>
> -- the name is already declared. So elements must be named, but nested
> element simpletypes not (where the name is identical).

Kon: you say "but nested element simpletypes not". Where in the XML
Schema spec does it say this? Not talking about what parsers do - but
what the spec says. If we can find where the spec definitely says they
MUST NOT, then this issue is resolved. Our schema is wrong (wrong =
does not conform to the XML Schema spec) and we need to publish in
errata.

I have looked all over the spec and it appears to be an area of
ambiguity, although I am not confident my research 100% covered what it
needed. I found a lot of places where it looked to be "allowed", but
then others that said names must be unique. Problem is that "unique"
did not specify if that was needed in parent-child situations whereby
the child is actually only a child by nature of nesting, as it serves
the purpose to further define the parent.  Here, let me show you what I
mean:

"Except for anonymous simple types (those with no {name}), since type
definitions (i.e. both simple and complex type definitions taken
together) must be uniquely identified within an ·XML Schema·, no simple
type definition can have the same name as another simple or complex
type definition."

Ok, that make sense, but it does not necessarily address our question.
Not too mention the fact that it is in a non-normative section of Part
1 of XML Schema
(http://www.w3.org/TR/xmlschema-1/#Simple_Type_Definition_details -
scroll down to first written paragraph), which was included as a cross
reference to Part 2 of XML Schema
(http://www.w3.org/TR/xmlschema-1/#Simple_Type_Definitions - see NOTE
under list of links for Section 3.14). Well, if you jump over the Part
2 (http://www.w3.org/TR/xmlschema-2/#dc-defn - again, scroll down to
first written paragraph) the language is slightly different, references
anonymous types, but neither clarifies or reinforces our situation.

So, where are we? Well, I think we are dancing all around the right
spots in the XML Schema spec, but I, for one, am just not knowledge
enough at this level of detail on XML Schema to definitely offer a
recommendation on or even a solid pointer to the solution. Probably
time, if no one else knows, for someone to ask the W3C XML Schema
Working Group (http://www.w3.org/XML/Schema) for some guidance.

Rex - as our historical liaison person, can you facilitate this?

> The .NET / Microsoft DOM parsers will validate the spec with the above
> modification.
>
> 2. I have had some older DOM parsers still cough up blood (Borland XML
> Mapper for C++Builder and friends is one). They can be repaired by
> changing:
>
> <simpleType>
> <list itemType = "string"/>
> </simpleType>
>
> to:
>
> <simpleType>
> <restriction base = "string"/>
> </simpleType>
>
> One reason could be that these incorrectly parse the XPath absolutely
> instead of relatively. Since there are simpletypes nested within
> complextypes and complextype by w3c definition cannot contain a list
> item, these fail.

Correct me if I am wrong, if I understand correctly what you are
saying, but just because <complexType> does not directly allow <list>
does not mean that a valid child or grandchild of <complexType>, such
as our <sequence> -> <element> - > <simpleType> situation, cannot have
<list>. In either case, this may also be a good question to ask the W3C
XML Schema WG.

Additional thoughts from anyone?

Allen
-------------------
R. Allen Wyke
Chair, OASIS Emergency Management TC
emergency-tc@earthlink.net

To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/emergency/members/leave_workgroup.php.


***************************************************************************************************
The information in this email is confidential and may be legally privileged.  Access to this email by anyone other than the intended addressee is unauthorized.  If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful.  If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system.
***************************************************************************************************


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]