[prev in list] [next in list] [prev in thread] [next in thread]
List: xml-dev
Subject: RE: [xml-dev] When is an XML vocabulary too =?UTF-8?Q?complex=3F=20The=20?= =?UTF-8?Q?art=20and=20sc
From: <w3c () drrw ! info>
Date: 2012-02-26 2:16:33
Message-ID: 20120225191633.df31abbe32f2d43023472a398044d65c.ce8ee0c422.wbe () email17 ! secureserver ! net
[Download RAW message or body]
<html><body><span style="font-family:Verdana; color:#000000; \
font-size:10pt;"><div>Roger,</div><div><br></div><div>Care to put this into context \
for us - are you talking about the <a href="http://NIEM.gov">NIEM.gov</a> \
schemas?</div><div><br></div><div>If so - notice there are 14 domains there - so \
you'd expect the vocabulary to be large - but each domains stewards of course are \
intimately familiar with their own content, but not necessarily the other 13 \
folks. That's natural.</div><div><br></div><div>Plus - 80% of the value of NIEM \
is nothing to do with XSD schema - instead its all about process and \
procedures.</div><div><br></div><div>Ensuring consistency of method and use is key to \
delivering predictable results that practitioners can assimulate and tool providers \
can then leverage and build to. NIEM has strong Naming and Design Rules (NDR) along \
with evaluation tools that report conformance and this takes the "noise" of XSD \
schema syntax itself out of the equation.<br></div><div><br></div><div>Therefore the \
lesson learned here when talking about large vocabularies is to get the management, \
discovery and reuse out of XSD schema syntax and maintain them as canonical component \
dictionaries with appropriate repository and versioning tools. \
</div><div><br></div><div>This should be done using syntax and methods that are \
semantically designed for the task. Schema was never intended to be used as a \
web-enabled collaboratively shared vocabulary of components, so no surprises that its \
gnarly to do with schema. Recall TBL was the one that decreed "no single point \
of failure" and hence XSD schema is very much a local file system based \
technology.<br></div><div><br></div><div>DW<br></div><div><br></div><div><br></div> \
<blockquote id="replyBlockquote" webmail="1" style="border-left: 2px solid blue; \
margin-left: 8px; padding-left: 8px; font-size:10pt; color:black; \
font-family:verdana;"> <div id="wmQuoteWrapper">
-------- Original Message --------<br>
Subject: RE: [xml-dev] When is an XML vocabulary too complex? The art<br>
and science of creating large, complex vocabularies that are amenable to<br>
teaching, learning, and using.<br>
From: "Len Bullard" <<a \
href="mailto:cbullard@hiwaay.net">cbullard@hiwaay.net</a>><br>
Date: Sat, February 25, 2012 4:18 pm<br>
To: "'Costello, Roger L.'" <<a \
href="mailto:costello@mitre.org">costello@mitre.org</a>>,<br> <<a \
href="mailto:xml-dev@lists.xml.org">xml-dev@lists.xml.org</a>><br> <br>
Given a DTD and multiple sources for content, for any valid instance what is<br>
the average time to code the instance given a measurable quality of coder?<br>
<br>
It can be complex given the range of the set of valid instances required of<br>
it. The question is what is the cost of selection over the number of<br>
options to find a valid solution given a candidate? If the production of<br>
the instance is constrained (ie, authoring enforces validity), then the<br>
complexity is managed. If not, it is discovered when the template is<br>
created.<br>
<br>
len<br>
<br>
-----Original Message-----<br>
From: Costello, Roger L. [<a \
href="mailto:costello@mitre.org">mailto:costello@mitre.org</a>] <br>
Sent: Saturday, February 25, 2012 1:43 PM<br>
To: <a href="mailto:xml-dev@lists.xml.org">xml-dev@lists.xml.org</a><br>
Subject: [xml-dev] When is an XML vocabulary too complex? The art and<br>
science of creating large, complex vocabularies that are amenable to<br>
teaching, learning, and using.<br>
<br>
Hi Folks,<br>
<br>
If an XML vocabulary is large and complex, does that mean it's bad?<br>
<br>
Calculus is a large and complex field of mathematics, does that mean<br>
Calculus is bad? Obviously not. <br>
<br>
........<br>
<br>
I am reviewing a large and complex XML vocabulary.<br>
<br>
Actually, I superficially reviewed it a few years ago and came to the<br>
judgment, "This is too complex, it's no good."<br>
<br>
Now I am patiently reviewing it in depth.<br>
<br>
The vocabulary has a lot of optional elements and attributes, so I am<br>
focusing on just the mandatory stuff and getting a firm understanding of it.<br>
<br>
<br>
Gradually, as the need arises, I will pick up the optional stuff.<br>
<br>
I've noticed that many Calculus books introduce the core concepts first and<br>
then describe the "non-core concepts" in later chapters. Presumably that<br>
makes it easier to learn Calculus.<br>
<br>
Is optionality in XML vocabularies the markup equivalent of "non-core<br>
concepts" in textbooks?<br>
<br>
In August there will be a conference on "What is Good XML?" <br>
<br>
Perhaps a characteristic of "good XML" is the frequent employment of<br>
optionality in elements and attributes?<br>
<br>
..........<br>
<br>
Calculus is very useful. It's used in everything from calculating the motion<br>
of planets to building bridges.<br>
<br>
But if all Calculus textbooks were written in a way that nobody could<br>
understand then I suspect that it wouldn't matter how useful Calculus is, it<br>
wouldn't be used.<br>
<br>
..........<br>
<br>
You may create the world's most useful XML vocabulary. <br>
<br>
But if nobody can understand it and teachers can't explain it then it won't<br>
be used.<br>
<br>
So, the design of an XML vocabulary involves more than usage. It also<br>
involves education and elucidation. Without the latter two, the former is<br>
for naught. <br>
<br>
Using optionality as a means of expressing "Hey, this is non-core<br>
information. You can learn it later if you need it" seems to be fundamental<br>
to the art and science of creating large, complex vocabularies.<br>
<br>
What do you think?<br>
<br>
/Roger<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________________________________<br>
<br>
XML-DEV is a publicly archived, unmoderated list hosted by OASIS<br>
to support XML implementation and development. To minimize<br>
spam in the archives, you must subscribe before posting.<br>
<br>
[Un]Subscribe/change address: <a \
href="http://www.oasis-open.org/mlmanage">http://www.oasis-open.org/mlmanage</a>/<br> \
Or unsubscribe: <a href="mailto:xml-dev-unsubscribe@lists.xml.org">xml-dev-unsubscribe@lists.xml.org</a><br>
subscribe: <a href="mailto:xml-dev-subscribe@lists.xml.org">xml-dev-subscribe@lists.xml.org</a><br>
List archive: <a href="http://lists.xml.org/archives/xml-dev">http://lists.xml.org/archives/xml-dev</a>/<br>
List Guidelines: <a \
href="http://www.oasis-open.org/maillists/guidelines.php">http://www.oasis-open.org/maillists/guidelines.php</a><br>
<br>
<br>
<br>
_______________________________________________________________________<br>
<br>
XML-DEV is a publicly archived, unmoderated list hosted by OASIS<br>
to support XML implementation and development. To minimize<br>
spam in the archives, you must subscribe before posting.<br>
<br>
[Un]Subscribe/change address: <a \
href="http://www.oasis-open.org/mlmanage">http://www.oasis-open.org/mlmanage</a>/<br> \
Or unsubscribe: <a href="mailto:xml-dev-unsubscribe@lists.xml.org">xml-dev-unsubscribe@lists.xml.org</a><br>
subscribe: <a href="mailto:xml-dev-subscribe@lists.xml.org">xml-dev-subscribe@lists.xml.org</a><br>
List archive: <a href="http://lists.xml.org/archives/xml-dev">http://lists.xml.org/archives/xml-dev</a>/<br>
List Guidelines: <a \
href="http://www.oasis-open.org/maillists/guidelines.php">http://www.oasis-open.org/maillists/guidelines.php</a><br>
<br>
</div>
</blockquote></span></body></html>
_______________________________________________________________________
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic