Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to Avoid Being Called a Bozo When Producing XML (2005)

hsivonen.fi

Post reply on HN
Print view View original

221–230 of 255 posts

Re: How to Avoid Being Called a Bozo When Producing XML (2005)

#221

Post by Mikhail_Edoshin »

maze-le wrote: post #198

Some XML dialects become very confusing if features are added as an afterthought without consideration of syntax and sematics. Microsofts Wordprocessing XML for example has caveats like w:permStart: (...) permStart and permEnd define regions where special permissions are required to edit a document. It is encoded in a complete anti-XML syntax, where different tags (and a common ID) represent the start and end of a re…

Microsoft Wordprocessing XML is very quirky :) I think they use these markers because different areas can overlap and thus you cannot express this with a tree-like structure.

Re: How to Avoid Being Called a Bozo When Producing XML (2005)

#222

Post by erlehmann_ »

lmm wrote: post #208
erlehmann_ wrote: post #153

Discussions about XML and JSON often remind me of this comment on HN: https://news.ycombinator.com/item?id=5702868 Partial quote: > XML can certainly be shorter than JSON and often is, and repeated tags are the best showcase for it: 123456789 321654987 > This turns into this beautiful JSON: [ "users": [ { "id": "abc", "phoneNos": [ { "type": "home", "value": "123456789" }, { "type": "work", "value": "321654987" } ] }…

Not a fair comparison since the JSON case includes the outer list as well. And whenever I've seen the equivalent of this in a real-world XML format it would use a tag to group the phone numbers together.

You probably have not looked too closely at real-world XML.

• Many XHTML and SVG elements can occur without dedicated wrapper elements.

• In Atom feeds, , , , elements can occur multiple times without a dedicated wrapper element.

• In XSPF playlists, , , , , elements can occur multiple times without a dedicated wrapper element.

Re: How to Avoid Being Called a Bozo When Producing XML (2005)

#223

Post by mbrock »

wtbob wrote: post #197
mbrock wrote: post #192

Earlier quoted context omitted.

I like S-expressions too, especially when generating markup programmatically. For hand-writing HTML/XML documents, which I do quite a lot, I really enjoy the tag style because of the verbose end tags and the ease of moving blocks. It's at least nice enough to make me annoyed when people claim the tag syntax is some horrible stupid disaster compared to S-expressions or (worse) JSON.

> For hand-writing HTML/XML documents, which I do quite a lot, I really enjoy the tag style because of the verbose end tags and the ease of moving blocks. I can't say anything about liking verbose tags, which seems to me a matter of taste, but moving around S-expression blocks is easy: C-SPC to set the point, M-C-f to move forward one S-expression, C-w to cut the current region, navigate to where one wants it, C-y to…

I also quite like Dylan's way of ending blocks, letting you type for example "end method do-stuff" so you can see clearly what's being ended, which is useful in a document with long sections.

And I like that XML block moving is even manageable with ed, which I actually use sometimes. Well, and vi.

Re: How to Avoid Being Called a Bozo When Producing XML (2005)

#224

Post by lmm »

erlehmann_ wrote: post #211
lmm wrote: post #209

Earlier quoted context omitted.

> Example: The XSLT stylesheet for this Atom feed generates a web page for each entry: http://news.dieweltistgarnichtso.net/notes/index.xml > In this setup, the Atom XML for each entry is generated from XHTML with XSLT, which makes it possible to automatically include an Atom enclosure element for every XHTML media element. To publish a podcast episode, it is enough to add a post with an or element. Sure. Why do you…

XML without namespaces does not exist. If it existed, how would you differentiate between title and link elements in Atom and title and link elements in XHTML? They have the same element names, but do not have the same meaning and therefore must be processed differently. Namespaces ensure that any XML processor can know the language of each part of the input. Namespaces actually are the general mechanism with which y…

> XML without namespaces does not exist. If it existed, how would you differentiate between title and link elements in Atom and title and link elements in XHTML?

By where it is in the structure. The document is a tree where each element has well-defined context; there should never be confusion about whether a particular is part of the feed or part of the content in the feed, because if it's in content it will be inside the content tag.

(Don't you need to do that anyway? I mean what if the XHTML had another Atom feed embedded in it? Or the content of one of the entries in the feed was another Atom feed? That's legitimate, but you wouldn't want to show titles from the "inner" feed as titles in the feed).

> Having an element with the semantics that “this content is in another language” is done out of necessity in HTML, as it has no namespacing: elements contain CSS, elements contain JavaScript, elements contain SVG … having an element in each language to embed each other language would become complicated very fast.

Only if you need the ability to embed an arbitrary other language. And if you do need that you can't possibly be validating or transforming based on what's embedded, so what value is the namespacing of it giving you?

Re: How to Avoid Being Called a Bozo When Producing XML (2005)

#225

Post by Mikhail_Edoshin »

rimantas wrote: post #89
ams6110 wrote: post #83

Earlier quoted context omitted.

XML could be fairly lightweight also. It was all the enterprisey-standard formats that were hideous. E.g. {"name":"John","age":42} vs.

Now do the nested objects in both. One line does not show much.
Here we can describe `person/@id` as element ID and `family-member/@ref` as a reference to an ID so our XML tools can link these together.

Also note three more elements from different namespaces: `@sec:checksum` could be some kind of technical information about the record, `fin:credit-rating` is added by the finanical module. The `@last-change` is defined as datetime so as we read it with other XML tools we'll get it as datetime type.

The next one is a tag in Russian language that describes something related to Russia; XML can use the whole Unicode in tag and attribute names.

Also, XML names are globally unique by design so there's no clash between all the different pieces and the tools can easily be configured to ignore parts they don't understand or work as a glue between different areas.

We can still efficiently validate the syntax the whole piece or parts of it as we see fit.

Re: How to Avoid Being Called a Bozo When Producing XML (2005)

#226

Post by lmm »

erlehmann_ wrote: post #217
lmm wrote: post #201

Earlier quoted context omitted.

It happens with any tree structure. E.g. I used to work on a system that managed reinsurance contracts and represented them as trees of contracts.

Did the elements often have immediate child elements that had immediate child elements (and so on) of the same type? Like: […]

No, there were a couple of layers in that case. But that doesn't actually help you add a child at the correct level, because the end of a contract would look something like:

                ...

Re: How to Avoid Being Called a Bozo When Producing XML (2005)

#227

Post by kozak »

colejohnson66 wrote: post #126
oceanswave wrote: post #107

Earlier quoted context omitted.

not valid. wondering if you've seen that within HTML, where it is valid.

Actually, now that you mention it, I think it's from Chrome's Inspect Element tool, but I can't check right now. I think if you wrote something like ... it would display in the tool as ...

Chrome's Inspect Element shows you the non-serialized DOM structure, which means it's neither XML nor HTML at that point.

Re: How to Avoid Being Called a Bozo When Producing XML (2005)

#228

Post by mbrock »

moron4hire wrote: post #215
mbrock wrote: post #196

Earlier quoted context omitted.

Such interleavings can actually be valid HTML5, in that the specification defines an algorithm for parsing that handles such "tag soup" in a reasonable way.

That's not the same thing as making interleaving valid.

What's the difference?

Re: How to Avoid Being Called a Bozo When Producing XML (2005)

#229

Post by Mikhail_Edoshin »

beagle3 wrote: post #49

I used to hate doing XML in Python - ElementTree was the nicest of them 10 years ago, but it still hurt. But last year, I discovered xmltodict[0] and since then, I don't really care - it makes doing xml (both reading and writing) no more cumbersone than using dicts, while still supporting stuff like namespaces, CDATA and friends. I still think XML is a horrible, misguided idea - from inception, but even more so in ho…

Python has a very good lxml module for advanced XML processing. You can define your own classes for XML elements, so you can read an XML file and get your own classes for the underlying elements. They're somewhat limited, you can easily define methods, but the data is locked to what's in XML. You can also define your own XPath functions and XSLT extensions. Comes very handy sometimes.

The API is still rather awkward though.

Re: How to Avoid Being Called a Bozo When Producing XML (2005)

#230

Post by erlehmann_ »

lmm wrote: post #224
erlehmann_ wrote: post #211

Earlier quoted context omitted.

XML without namespaces does not exist. If it existed, how would you differentiate between title and link elements in Atom and title and link elements in XHTML? They have the same element names, but do not have the same meaning and therefore must be processed differently. Namespaces ensure that any XML processor can know the language of each part of the input. Namespaces actually are the general mechanism with which y…

> XML without namespaces does not exist. If it existed, how would you differentiate between title and link elements in Atom and title and link elements in XHTML? By where it is in the structure. The document is a tree where each element has well-defined context; there should never be confusion about whether a particular is part of the feed or part of the content in the feed, because if it's in content it will be insi…

> The document is a tree where each element has well-defined context; there should never be confusion about whether a particular is part of the feed or part of the content in the feed, because if it's in content it will be inside the content tag.

In this specific case, maybe – but generally, it is not true that you can infer the namespace of an element from context. Also, elements can have multiple attributes with different namespaces (and often do).

> I mean what if the XHTML had another Atom feed embedded in it? Or the content of one of the entries in the feed was another Atom feed? That's legitimate, but you wouldn't want to show titles from the "inner" feed as titles in the feed

That actually appears to be a bug in my stylesheet. Thank you for bringing it to my attention!

Programs often use namespaces to provide metadata. Here is an SVG I created with Inkscape that uses six different namespaces for metadata: http://daten.dieweltistgarnichtso.net/pics/icons/minetest/mi... Thanks to namespacing, web browsers can display the picture while ignoring Inkscape-specific data.

> Only if you need the ability to embed an arbitrary other language. And if you do need that you can't possibly be validating or transforming based on what's embedded, so what value is the namespacing of it giving you?

It is very useful to embed any arbitrary language, as XML processors can preserve the content they do not understand without processing it. My XSLT stylesheet would have no issue with SVG embedded in XHTML, just as your web browser most likely ignores everything about the SVG linked above it can not understand.

Post reply on HN