>
>TA
>> The very idea of schemas for JSON is anathema to many JSON users,
>> so don't expect much support from the community for this.
>
>I agree that unrestricted JSON is a meaningless notation. It's worse
>than unrestricted natural language, because it provides the *illusion*
>of being precise.
True. Keep in mind that JSON was not intended to be a heavyweight,
interchange for everything language (Read:
http://tools.ietf.org/html/rfc4627 ). The deign goals were for a
lightweight language that had very terse syntax for un-ambiguity in
parsing and supported a minimal set of both ordered and unordered lists.
It is precise in terms of parsing. There are no semantics associated with
it and this was never a design goal so in that respect it is meaningless
as there are no normative key-value pairs that one must or must not use. (01)
I like this feature however as it increases the scope for where developers
can use it for pure interchange. JSON itself cares not about what it is
expressing. (02)
>
>TA
>> The XML schema description language (XSD) certainly has many
>> shortcomings, but there are other options, especially Relax NG,
>> NVDL and Schematron (http://dsdl.org/), all supported by tools
>> like oXygen (http://oxygenxml.com)
>
>The growth of multiple specification languages is fine -- provided
>that there is a systematic way to relate their semantics to one
>another. (03)
DN: Confused. No XML Schema language is concerned with semantics in
itself other than the structural and canonical restrictions that it
declares instances must comply with. Semantics were not a design goal
other than developers and parsers would be able to unambiguously
understand what the structure of a valid instance of XML must be. Some
failed at this and even the processing models do not resolve the
conflicts. I commented on one of the last input periods to help the W3C
fix the errors. (04)
Consider this: (05)
<xs:choice>
<xs:element name="element1" minOccurs="1"/>
<xs:element name="element2" minOccurs="1"/>
<xs:choice> (06)
This is perfectly fine yet it creates a conflict in logic that needs to be
resolved. I have not yet checked if they fixed this one yet but it was
one of many comments i made. (07)
Another problem is the ability to serialize UML into XML. In straight up
UML, you can have multiple occurrences of an attribute yet in XML the
constraint is to allow only one uniquely worded attribute per element. (08)
Consider: (09)
+ AttributeName : TypeName [3] (010)
in a Class view Diagram. You cannot easily just assume that the UML
elements and attributes can be converted to XML elements and attributes.
Instead, you have to build a structure that uses nested elements inside of
the parent element to allow the cardinality to appear however the
relationship that the inner elements are attributes of the parent are
somewhat lost. (011)
<sigh> (012)
Duane Nickull (013)
>
>There will never be "One ring to rule them all." But we can have
>better methods for relating them and supporting interoperability.
>
>John
>
>_________________________________________________________________
>Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
>Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
>Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
>Shared Files: http://ontolog.cim3.net/file/
>Community Wiki: http://ontolog.cim3.net/wiki/
>To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J
> (014)
_________________________________________________________________
Message Archives: http://ontolog.cim3.net/forum/ontolog-forum/
Config Subscr: http://ontolog.cim3.net/mailman/listinfo/ontolog-forum/
Unsubscribe: mailto:ontolog-forum-leave@xxxxxxxxxxxxxxxx
Shared Files: http://ontolog.cim3.net/file/
Community Wiki: http://ontolog.cim3.net/wiki/
To join: http://ontolog.cim3.net/cgi-bin/wiki.pl?WikiHomePage#nid1J (015)
|