[Home] [By Thread] [By Date] [Recent Entries]

  • From: Kurt Cagle <kurt.cagle@g...>
  • To: Peter Flynn <peter@s...>
  • Date: Sat, 18 Feb 2017 15:28:14 -0800

I'll echo the general sentiment that it matters more in documents than it does in encoding of data. 

For data, I typically use the convention that attributes are either for keys or key references, 

<employees>
<employee id="emp110">
     <name>Jane Doe</name>
     <worksFor idref="emp111"/>
</employee>
<employee id="emp111">
     <name>Graham Kerr</name>
</employee>
</employees>

This is mainly because this echoes RDF usage. 

<rdf:RDF>
<employee rdf:about="company:employee#emp110">
     <name>Jane Doe</name>
     <worksFor rdf:resource="company:employee#emp111"/>
</employee>
<employee id="company:employee#emp111">
     <name>Graham Kerr</name>
</employee>
</employees>

You could also encode datatype, but this can be as readily expressed as schema.



Kurt Cagle
Founder, Semantical LLC



On Sat, Feb 18, 2017 at 3:10 PM, Peter Flynn <peter@s...> wrote:
On 02/18/2017 06:33 PM, Ihe Onwuka wrote:
> I found this quote in an article by Bruce Johnson
>
> The single biggest tradeoff and architecture question you need to
> answer – do you want complexity in the data or in the usage.
>
> I agree with it. You do not get a free lunch by using a "simpler"
> data format unless your domain of concern is relatively trivial.

Actually I think your last sentence is even better. It phrases politely
what many of us might say more forcefully among ourselves.

> Which brings up a seldom mentioned point. JSON is a developer
> centric format. Who other than a developer would want to encourage a
> state of affairs that requires more and more functionality to
> manifest as application code

I think that's a little harsh — it reminds me of the old joke about
COBOL being the language of choice among programmers wanting to enhance
their long-term employment prospects. Which was funny in the late 1970s
but has now become embarrassing.

There are certainly developers mature enough to select a data format
that is appropriate for the task, and who are well aware of the balance
between complexity in the data format and complexity in the processing.

> On Fri, Feb 17, 2017 at 2:38 PM, Ihe Onwuka <ihe.onwuka@g...> wrote:

> Well XML vs JSON is an issue is because the JSON community see their
> ecosystem as replacing rather than co-existing alongside other
> ecosystems (XML in particular).

But the JSON community are programmers. XML _per se_ has nothing to do
with programming.


> On Thu, Feb 16, 2017 at 8:32 AM, Rick Jelliffe <rjelliffe@a...> wrote:
>
> Here is kinda how I see it. How do others see it?
>
> *         |        Fields       |    Literature
> -----------------------------------------------
> Ephemeral | ie messages: JSON   |     HTML
> -----------------------------------------------
> Stored    | ie records: XML+XSD |     XML

But I now frequently find Stored/Fields using JSON.


> On Thu, Feb 16, 2017 at 11:00 PM, Costello, Roger L. <costello@m...> wrote:
>
> Isn’t XML necessarily about data, i.e., data-focused, data-centric?

Nope. Nothing whatever to do with it. XML is for text. Its use for data
is a great convenience in some circumstances, but that's not what it was
designed for.

///Peter

_______________________________________________________________________

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@l....org
subscribe: xml-dev-subscribe@l....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]


Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member