XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
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 looksthe same?

Enjoying (and biting my tounge) on this discussion since Balisage.

Totally agree with Kurt it’s a trade-off issue and the arguments on both sides are reasonable *in context* … but where I want to bite my tounge

Is a black and white statement like “Using schemas are bad” or “Flexibility is always good”

This last email from kurt unpinned an old neuron …

For those who haven’t, or haven’t recently I highly recommend this short classic

“In the beginning was the command line”

A quick read , for free from the author directly (with permission, no strings )

 

http://www.cryptonomicon.com/beginning.html

1999

Or if you would rather pay $10

http://www.amazon.com/Beginning-was-Command-Line-Neal-Stephenson/dp/0380815931

 

I wont spoil it for you but the ending is great.

 

It is a short essay on the comparison of Windows vs Linux evolution, focusing on the business model and the GUI

Where Linux is the metaphore for “flexable and free” and windows is the metaphore for “constrained and commercial”

 

I think the comparison to schema vs schema free is quite close … a bit off … but speaks better then I can about the tradeoffs

And what happens if you go one way or the other too far.

 

 

----------------------------------------

David A. Lee

dlee@calldei.com

http://www.xmlsh.org

 

From: Kurt Cagle [mailto:kurt.cagle@gmail.com]
Sent: Wednesday, August 28, 2013 11:24 AM
To: Lauren Wood
Cc: xml-dev@lists.xml.org
Subject: 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

443-837-8725

 

 

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.

Lauren



_______________________________________________________________________

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