Lists Home |
Date Index |
I am having a hard time accepting the case for mixed content, especially
based on the arguments I have seen. I thought one of the key points of
schemas was to provide validation mechanisms to allow bad content to be
rejected before it got to the application processing level. In the examples
given, I can see alternate ways to write the schemas that don't use mixed
content that would provide better validation mechanisms.
In the case of the E-mail example, I would think you would want the E-mail
address wrapped inside an extra element. This would provide the ability to
specify a pattern constraint to make sure it is indeed in the format of an
E-mail address if that is what you were expecting it to be.
In the case of addresses having many different formats, I would think a
choice construct which enumerated the known formats would be better. This
construct could contain an <xsd:any> wildcard at the end to catch those
items that did not fit the known patterns.
I suppose this is case of "document-centric" vs "data-centric" application
thinking (I am in the latter camp). It would seem this might be a good
place to start when breaking down schema profiles.
Objective Systems Inc.
----- Original Message -----
From: "Elliotte Harold" <email@example.com>
To: "Michael Kay" <firstname.lastname@example.org>
Cc: "'Peter Gerstbach'" <email@example.com>; "'XML-dev'"
Sent: Friday, July 15, 2005 7:06 AM
Subject: Re: [xml-dev] Mixed content in data-binding (Was: Re: [xml-dev]
Interesting pair of comments
> Michael Kay wrote:
> I don't like this example. As I see it the natural interpretation of
> this construct is that the e-mail address is
> firstname.lastname@example.org. I don't think this is a good use of a
> mixed content. I would write this construct as:
> Here what's needed is better support for sibling elements.
> A better example might be:
> Here the username element contains exactly and only the username; the
> host element contains exactly and only the host; and the email element
> contains exactly and only the email address.
> This would be even more compelling with street addresses, where many
> different unplanned things can show up as part of the address in a
> different country, and where the boundary whitespace might be used to
> format the address when printed on an envelope.
> Elliotte Rusty Harold email@example.com
> XML in a Nutshell 3rd Edition Just Published!
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
> The list archives are at http://lists.xml.org/archives/xml-dev/
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>