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


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Re: [xml-dev] Do you enjoy neighborhoods where every house looks the same?

To me, it's an issue of trade-offs. Standardization, which I think is at the root of Simon's comments, is efficient - you in effect create a single set of designs, making it possible to custom manufacture parts or pieces in parallel for many different projects simultaneously. What you lose with that efficiency is flexibilty - the ability to move outside of the standard, to add embellishments on the design to fit specific needs. This is true of data modeling regardless of whether you're talking about UML, XSD or (to an extent) OWL.

In theory, the RDF open world assumption mitigates this somewhat; you define the behavior of a model for those cases where you need specificity, but unless you specifically disallow it you do not implicitly disallow non-standard relationships - the analogy of customization or ornamentation. Of course, the downside to this is that the non-standard components do not then have rules specifying their behavior, because they are, by definition, outside of the schematic model being created. In practice, what this usually means is that your schema makes an assumption that those parts that are not defined within that schema will be defined at some point by some other schema. This corresponds (roughly) to xsd:any with lax validation. 

Of course, I've seen way too many XSD schemas that were designed in such a way as to not allow for this escape hatch, and indeed, a lot of tools that utilize XSD schemas - such as JAXB for Java object serialization of schemas - go positively crazy in the presence of xsd:any. That has to do more with the fact that most people do not understand validation or data modeling with a hatch for flexibility than it does with tools. They see validation as binary (something is or is not valid) rather than contextual (something is this valid in that context). This becomes more evident when you create contextual bindings (such as XSD 1.1 or Schematron), but neither has achieved the degree of awareness that XSD has, principally because XSD 1.0 is so inextricably bound up with WSDL.

Kurt Cagle
Invited Expert, XForms Working Group, W3C
Managing Editor, XMLToday.org

On Wed, Aug 28, 2013 at 10:23 AM, Lauren Wood <lauren@textuality.com> wrote:

On 28-Aug-13 8:57 AM, Jeremy H. Griffith wrote:

The idea is that if the parser can tell what is missing
or incorrect, and correct it, it will do so, warn you,
and proceed.  This is John Cowan's idea in the MicroXML
spec.  So for example if you have:

   <p>This is <b>bold.</p>

the parser can reasonably guess you meant:

   <p>This is <b>bold.</b></p>

Or if the character after the equals in an attribute
is not a quote, it can supply one.  There are quite a
few places the parser can make a reasonable guess.
Like, ",p>" might have been meant to be "<p>", with
the Shift key not in sync for the first character (a
personal favorite typo for me ;-).

The hard part with these fixes is knowing when to stop. The law of diminishing returns kicks in fairly quickly on error conditions, especially when the schema isn't constrained. For example, it's much easier to correctly correct the missing end tags when the schema is constrained (e.g., you at least know which elements are meant to be empty, and which not). In my experience if your parser makes the wrong choice and therefore 'corrects' the wrong thing, or corrects it in the wrong way, the resulting mess can be difficult to fix properly. Of course, depending on your downstream processing, that may or may not matter.



XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php

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

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS