标签: xml

什么是XML文件？ 在软件的配置选项中，经常可以看到XML文件的身影。XML文件的全称是：Extensible Markup Language（可扩展标记语言），它定义了代码文件的一系列规则，它的格式既方便人阅读，也方便机器阅读。XML文件的规格全部是开源的。 XML文件的设计规则是简单、通用、易用。它的规格和解析工具都在不断完善。 关键术语： Character：XML文件里面几乎可以出现任意字符。 Processor和Application：处理器会分析标签，将结构信息传送给应用。XML的规格要求了处理器必须执行和禁止执行的操作，但是应用不受此限制。Processor通常被称为parse（解析器）。 Markup和content：标记和内容。标记通常以 开始，以 结束，或者以 开始，以 ; 结束。 Tag：标签。标签采用了标记的结构，它分为三种： 起始标签： 结束标签： 空白标签： Element：元素。元素由一组起始标签和结束标签（或者一个空白标签）构成。元素可以包含元素，被包含的元素称为子元素。 Attribute：属性。属性也采用标记结构，属性的名称和值放置在起始标签或者空白标签中，比如： 或者： 一个属性只能包含一个值，任一属性只能在一个元素里出现一次。如果值需要表示为一个列表，则在值本身定义，比如： Welcome! XML Declaration：XML声明，比如： 另外，可以使用预定义的字符串表示特殊的标记字符： lt，表示 gt，表示 amp，表示 apos，表示 ' quot，表示 有关注释： XML文件的注释可以出现在Markup外的任何地方。注释以 结束，同时 -- 不允许出现在注释中，因此注释不可嵌套。 ------------------------------ 有关错误处理： XML解析器解析XML文件时，遇到错误的语法就会停下来。这种策略被称为draconian error handleing。与之相反的是HTML，HTML是即使遇到错误，也会给出尽可能多的结果，这种策略被称为 Postel's law。 ------------------------------ 以上是XML文件的基础。基础中的基础知识。XML的规格有很多种，解析工具也有很多，程序使用它的接口也有很多，这些以后用到的时候再学习。本次笔记就到这里。

  CoAP is a web transfer protocol optimised for resource constrained networks typical of IoT and M2M applications. It is based on a REST architecture in which resources are server-controlled abstractions made available by an application process and identified by Universal Resource Identifiers (URIs).   The first significant difference between HTTP and CoAP is in the transport layer upon which they rely. HTTP relies on the Transmission Control Protocol (TCP), which uses a flow control mechanism ill-suited for LLNs. Moreover, its overhead is considered too high for short-lived transactions.   By comparison, CoAP is built on top of the UDP and therefore has significantly lower overhead and is capable of multi-cast support. To maintain all of the performance and resource advantages of UDP without giving up the reliability of the full TCP/IP, CoAP is organised into two layers.   The Transaction layer handles the single message exchange between end points. Four types of messages are handled by this layer: Confirmable (requires an acknowledgment), Non-confirmable (does not need to be acknowledged), Acknowledgment (acknowledges a Confirmable message) and Reset (indicates that a Confirmable message has been receive but context is missing to be processed).   The Request/Response layer is responsible for the transmission of requests and responses for the resource manipulation and transmission. This is the layer where the REST-based communication occurs. A REST request is piggybacked on a Confirmable or Non-confirmable message, while a REST response is piggybacked on the related Acknowledgment message.   Everything I read by the proponents of COAP argues that the use of this dual layer approach allows it to provide reliability mechanisms even without the use of TCP as the transport protocol. This is because a Confirmable message is retransmitted using a default timeout and exponential back-off between retransmissions, until the recipient sends the Acknowledgement message. An important aspect of COAP as far as response time is that when a server receives a request which it is not able to handle immediately, it first acknowledges the reception of the message and sends back the response in an off-line fashion.   To keep the message overhead as small as possible and avoid the significant overhead that the standard HTTP mechanism requires, COAP uses a number of techniques that will require embedded developers to carefully parse their impact on system response times and deterministic operation.   First, CoAP uses a short, fixed-length, compact binary header of 4B followed by compact binary options. A typical request has a total header of about 10-20B. Because a resource on a CoAP server will more often than not change over time, the protocol's been designed to allow a client to constantly observe the resources. The way this is done is that the client (the observer) registers itself to the resource (the subject) by means of a modified GET request sent to the server.   The server establishes an observation relationship between the client and the resource. Whenever the state of the resource changes, the server notifies each client having an observation relationship with the resource. The duration of the observation relationship is negotiated during the registration procedure. While not as neat and efficient as a purely UDP approach, it seems to resolve many of the performance issues.   Second, CoAP also supports other payload encoding standards, such as the widely used Extensible Markup Language (XML), but not your common ordinary garden-varity version. As it is presently implemented, the verbosity and parsing complexity of XML makes it inappropriate for constrained devices. One alternative is the more compact data representation in JSON.   JSON (JavaScript Object Notation) is a lightweight, text-based open standard designed for human-readable data interchange. It is derived from the JavaScript scripting language for representing simple data structures. But what JSON lacks is the flexibility of XML. As a result there are ongoing efforts to develop more compact binary XML-based representations such as the Extensible XML Interchange (EXI).   There is still a lot to learn about the impact of 6LoWPAN, COAP, and other protocols and how embedded developers can take advantage of them. I am still wading my way through the many articles and standards documents trying to learn as much as I can as fast as I can. In relation to COAP and its use of UDP, I still have a lot of questions.   First, even with all the thought that's been put into 6LoWPAN and into such protocols as COAP, will it be enough to penetrate more than the a small portion of embedded applications, especially those in hard real-time and deterministic applications in machine control and industrial control? The original uses of UDP were in wired networking applications that were by-and-large isolated from the outside network and so could make compromises on security and reliability. Not so in 6LoWPAN environments, which are naked to the world and require connectivity to the wider Internet.   Second, compared to the minimalistic UDP implementations that I have seen in the past, the UDP implementation within COAP is positively pudgy. Would this eliminate its use in most sensor networks using 8- and 16bit MCUs?   Third, why was the UDP subset the one that was chosen? Because of the sparse resources it requires, it was certainly most obvious choice. However, there are other variations, such as the TCP extensions for Transactions (T/TCP) that might have been a better starting point. While more complicated and less resource-efficient, T/TCP would be a case of taking one step back in order to take two steps forward: Even though it requires slightly more memory and is less efficient in terms of bandwidth than UDP, it has features that the COAP implementers had to add in to their UDP-derived scheme after the fact.   What is missing in almost everything I have read is an informed embedded systems developer's perspective. For that I look to you, in your comments here.    

Because XML is at the heart of what is being called the 'embedded cloud," and is in wide use in embedded development as a powerful data representation framework, there needs to be as much discussion of its strengths and weaknesses and how to deal with them as is now devoted to C or C++. Embedded tool vendors, microprocessor architects, EDA companies, and FPGA firms are finding many clever ways to use XML (Extensible Markup Language) , but with only a few exceptions I can seldom get them to go into detail about their projects. They appear to think that what they are doing is a secret they do not want to advertise widely or that their use of XML is too mundane to bother talking about, like sprinkling salt on your eggs in the morning. But I hope this will be changing given the recent announcement by the European Union of the completion of the INTERoperable Embedded Systems Tool chain for Enhanced rapid Design ( INTERESTED ) project. XML is the underpinning of a cooperative effort by a team of companies that includes AbsInt Angewandte Informatik (Germany), Atego (UK), CEA (France), Esterel Technologies (France), Evidence (Italy), Symtavision (Germany), Sysgo (Germany) and TTTech Computertechnik (Austria). XML is going to be a part of all embedded developers' lives for at least two reasons. First, it is an integral part of the Web protocols that must now be included in many network and cloud-connected designs. Second, and more importantly, it has data structuring features that make it a useful tool in the embedded design environment. Because of this there needs to be as much discussion of its strengths and weaknesses in the embedded systems environment and how to deal with them as is now devoted to C or C++. I hope you will use Embedded.com and ESD Magazine as the forum for that discussion. XML is not a language in the same way C, C++, or Java is, of course, but rather a set of rules developed by the World Wide Web Consortium for encoding documents in machine-readable platform-independent form The design goals of XML emphasize simplicity, generality, and usability over the Internet. Although the intent of XML is the creation of Web documents, it is used for the representation of arbitrary data structures, for example in Web services. It is in this ability to represent a number of different data structures that XML is finding most use in embedded systems designs. For example, consider the experience of Karen Wang, who in "Use XML to build ASIC or SoC design specifications," explains that as senior embedded software engineer at SiBEAM, Inc. she was faced with the problem of distributing the hardware specification created by the company's ASIC engineers to other teams for hardware validation, embedded software development, and data sheet documentation. "Unfortunately, no standardized tools to document and distribute the specification existed," she writes, "so ASIC engineers often use Microsoft's Word, Excel, or a text editor." What XML provides is a mechanism to easily convey a hardware specification. Moreover, she said, XML is easy and intuitive to learn and the amount of training required for hardware engineers to use XML is relatively small. "Expertise is only required in the schema creation and style sheet design, which can be owned by one or two engineers," Wang says. According to Jon Pearson in "Building correct by design embedded systems," at Cypress Semiconductor XML was used to build the configuration environment framework for the company's PSoC Express design tool. The tool makes use of data-driven techniques to monitor resource usage for programming an microcontroller, providing an organized way for the programmer/developer to organize configuration and design information. At Polycore, a provider of tools for multicore software development, XML is at the heart of its Poly-Messenger and Poly-Generator offerings. Poly-Messenger is a run-time software component that implements inter-core communication based on the Multicore Communications API, or MCAPI. Poly-Generator is a tool that is used to specify the communication topology. The system designer creates an XML file that defines resources on a per-node basis, where nodes can be either physical (i.e., a particular core) or logical (i.e., there can be multiple nodes within a single core). Up until the INTERESTED project, the most impressive use of XML in embedded systems design to date is the automotive industry's AUTOSAR common embedded tool chain, in which XML is used to define the data interchange formats that allow fine-grained distribution of data to be distributed amongst the various the various tools used by the different teams of developers or members of teams. According to a recent news report, the participating companies in the INTERESTED project said that the XML-based reference tool chain has been evaluated and validated by a host of European embedded tool users on practical applications against real-world design interoperability and cost-reduction requirements. These included Airbus Operations S.A.S (France), Thales (France), CEA (France), and Siemens Mobility Division, Rail Automation (Germany) and Magneti Marelli (Italy). One company, Thales, reported that compared to freeform alternatives, the use of the new tool framework resulted in a 25 percent reduction in overall project effort, a 10 percent reduction in the time spent on modeling and a 25 percent reduction in the number of remarks raised by design reviewers. Although most embedded hardware and software companies don't talk much about how they are using XML, virtually every EDA company, software tool vendor, and processor company makes use of it. One measure of XML's ubiquity is patent activity. A search of the U.S. Patent Office reveals that since 2005 about a dozen embedded hardware and software companies I deal with regularly have applied for or received over 1,100 patents relating to the use of XML. I've also been talking to designers who are making use of XML in their development environments. A few of them have volunteered to write articles for embedded.com on their experiences, which you can be expect to see on line or in the magazine in coming months. Given its growing ubiquity in a variety of hardware and software design environments, I look forward to seeing more contributions from you on the topic of XML and how you use it in your designs. Or that you don't use it, and why, and what you use as an alternative.