text:
The invention discloses an apparatus and a method for identifying nodes in a node-based data source, the apparatus being unique node identifiers, or series of unique node identifiers. The identifiers remain unchanged despite transformations of the data source. Any modification made to data derived from the transformations is also effected at the data source by means of the identifiers, the identifiers mapping the data in the transformed version of the data source to the data in the data source.
1. A method of identifying data in a node-based data source comprising the steps of annotating at least one node with a unique identifier.
2. A method according to
3. A method as claimed in
4. A method as claimed in
5. A method of modifying a node-based data source comprising the steps of:
associating selected nodes in the data source with identifiers;
identifying a node to be modified by reference to its identifier; and
modifying the node data.
6. A method as claimed in
the corresponding node in the separate transformed version and the node in the source document have the same identifier.
7. A method as claimed in
the corresponding node in the separate transformed version and the node in the source document are mapped to each other by a series of identifiers;
each identifier in the series representing a transformation in a series of multiple-transformation.
8. A method as claimed in
9. A method as claimed in
10. A method as claimed in
deleting the selected node in the data source.
11. A method as claimed in
inserting a node in the transformed version of the source;
updating the data source by creating a counterpart node corresponding to the inserted node; wherein
the counterpart node is positioned in the data source in dependence upon at least one property of one or more nodes in the transformed version.
12. A method as claimed in
13. A method as claimed in
14. A method as claimed in
modification cannot be effected on the node without an identifier.
15. A data source structured to operate as a node-based data source wherein at least one node is associated with a unique identifier.
16. A data source as claimed in
17. A data source as claimed in
18. A data source as claimed in
19. A method of annotating a transformed version of a data source comprising the steps of:
copying identifiers in the nodes in a data source to corresponding nodes in the transformed version of the data source.
20. A method as claimed in
21. A method as claimed in
22. An identifier which is capable of uniquely identifying a node in the data source and also a corresponding node in a transformed version of the data source; whereby
the node in the data source is mapped to the corresponding node in the transformed version of the data source.
23. An identifier as claimed in
unchanged despite modifications to the data source structure or the data source itself; and
unchanged despite modifications to the structure of or the data in the transformed version of the data source itself.
24. An identifier as claimed in
the display state of the transformed data source before an update action is returned to that same state in the display after an update action and a refresh of the display.
25. An identifier as claimed in
identifiers derived from user names.
26. An identifier as claimed in
identifiers derived from system names.
27. An identifier as claimed in
identifiers derived from system names and identifiers derived from user names.
28. An identifier as claimed in anyone of
29. A data transformation engine comprising:
means of copying identifiers of nodes in the data source and Inserting the identifiers into the nodes of the transformed version of the data source; whereby
the nodes in the transformed version of the data source are mapped to their corresponding nodes in the data source.
30. A thin-client system implementing the methods as claimed in
a separate server system in which the transformation takes place;
a separate client system being a system for display of the transformed version of the data source.
31. A fat-client system implementing the methods as claimed in
a separate server system wherein the data source resides;
the separate client system which receives the data from the server system and in which the transformation of the data source takes place.
32. An industrial standard of node-based document modification adopting the methods as claimed in any one of
33. An industrial standard of identification of nodes in a node-based document adopting the identifiers as claimed in anyone of
34. An industrial standard of node-based data transformation adopting the engine as claimed in
35. A method as claimed in any one of
36. A data source as claimed in any one of
37. An identifier as claimed in any one of
38. An data transformation engine as claimed in
39. A thin-client system as claimed in
40. A fat-client system as claimed in
The present invention relates to a data source updating method from transformed data.
There are currently several types of database structures of which the most common examples are the flat file database structure, the relational database structure and the hierarchical database structure.
Most database programmers are familiar with relational databases (e.g. MsSQL. Oracle), and fiat file databases (e.g. such as a text file with delimiters).
Data in text files or relational databases can be easily retrieved and updated. A line of data to be modified in a text file database is simply inserted, deleted or updated by direct user action in a text editor, from a simple script program or an advanced user interface program. If the data in a relational database is to be modified, this can be easily done by an insert, delete or update command in a query language such as SQL, which uses foreign keys and selection criteria to modify related tables.
An example of a hierarchical database structure is XML. In an XML database information is arranged in such a manner that data �drills down� into branches of the database to retrieve the information required. This can be imagined as a tree with many levels of branches, and the data at the ends of the branches is classified according to the branches. In other words, XML source documents consist of data structured into �trees�.
XML data is usually used by, for example, XSL processors to produce an output result. Typically, a process begins with a source tree (or source document), and ends with a result tree (or result/transformed document, which may be any type of marked up document or simply a text document). Central to a data tree is the concept of nodes, which are data objects categorised as �branches� of the tree. There are several node types, and these are known to the man skilled in the art. A simplified example of the types will be given here using the incomplete XML document shown below:
1. Root nodes: There can only be one root node because it represents the document itself. The root node of the XML document is the whole of the document.
2. Element nodes each represent an element and usually consist of a pair of the element tags. The root element in the example is <Elmt1></Elmt> The first child node of the example is another element, <Elmt2></Elmt2>. Sometimes, elements may not be defined by tag pairs but by a singular tag, such as <br> in HTML, which is simply a line break. Element nodes usually contain textual information.
3. Text nodes consist of character data, or text or strings, e.g. �Hello World�. Generally, text nodes are found encapsulated in element nodes.
4. Attribute nodes contains information on attributes, such as text styles etc which are scripted inside element tags.
5. Namespace nodes: Each element has a namespace node corresponding to its namespace prefix such as �xsl:�. Such nodes ensure that different elements with the same name, or different attributes with the same name and in the same element, can be distinguished. Namespace nodes are optional in XML documents and are not always be used.
6. Processing instruction nodes: contains processing instructions.
7. Comment nodes contains comments which are enclosed in <l--comments-->.
As a further example of the nodes in an XML document, the line of code:
A powerful feature of XML is that it provides a way of data sharing between different data systems, regardless of how the data is structured. The syntax structure of XML is similar to that of HTML, and the tags to identify the purpose of each piece of data, except that users define the tags themselves. This provides versatility in data classification and identification. As a result, XML imparts inter-system transportability to data.
An XML document's tags are interpreted, or the data therein selected and manipulated in a process called �transformation� or �query�, depending on the type of XML processing script used. The output of the transformation may be data encoded in HTML syntax, or another XML document. The transformed XML document encodes selected data in tags defined by a recipient user so that the data may now be recognised by the recipient user's system. Therefore, XML does not have the conventional difficulty of data migration between databases with different table structures as with the relational database structure. Examples of such transformation/query technologies are XSLT (Extensible Stylesheet Language Transformation) or XQuery. The use of XQuery and XSLT is well known to a man skilled in the art.
The present limitation of XML is that there is no standard way by which modifications may be made to XML data through a script language, unlike in a relational database (e.g. SQL). XML updates have to be made through a text editor, or if the XML document is generated from a relational database, the document has to be regenerated after the information has been updated in the relational database.
Referring to the example below, if an XML document user wants to correct the title �Mr Chew's Life� to �Mr Chew's Other Life�, he has to look for the element node, <bio></bio>, containing the text node �Mr Chew's Life�, and then type over the book title in a text editor to change it (the book titles enclosed in the element tags are nodes in their own right, known as text notes).
Furthermore, if the modification of XML data is to be initiated on a transformed XML document, in such way that a corresponding update in the source document is effected as well, the updating action is then no longer just a straightforward replacement of data in through a text editor. At least two documents will be involved now, the transformed document and the original source document. Modifications to the data in the transformed document must be properly reflected in the correct source document(s).
The update action becomes particularly difficult if it involves deletion or insertion of element nodes such that the structure of the transformed XML document changes and the software engine for updating the source nodes relies on mirrored node positions between the source and transformed document to link them.
Current technologies, such as XPath, XPointer and XQuery are known technologies which define node positions in an XML document by the nodes' sequential order or by indexing the nodes. However such node positions are not persistent through editing actions.
A transformation/query performed on an XML document is analogous to an SQL query. However, re-arranging, inserting and deleting data in an XML source document through actions on a transformed document is presently impossible, especially if the XML structure is modified. Node indices, i.e. ordering of node positions, are not persistent when sibling elements are inserted, removed or re-arranged, making it impossible to maintain proper links between a source XML document and the transformed XML. document after multiple transformations or queries. Due to these limitations, it is difficult to manage an XML document like an SQL database.
US patent application 20030037303 proposes a mechanism for reversing XML transformations, which allows updating of data in an XML source document by actions through a user interface displaying the transformed document. Referring to
However, often transformations do not always consist of a single step process. In sophisticated XSLT and XQuery transformations, such as a multi-step transformation, the nodes in the resultant document may not have a one-to-one mapping mirroring the original nodes in the source document.
For example, an XML source document having one parent element node, two child element nodes, each of which contains one text node, such as that shown in
Furthermore, if instead of just processing one source document, several source documents are used to extract a resultant transformed document, an inverse XSLT transformation script of the kind proposed in US patent application 20030037303 has no way of determining from which of the original documents does a piece of data in the resultant document come and which source document therefore to update.
The present invention aims to provide a data source structure and a method of operating upon that structure to assist in updating of a database by operation on data transformed or extracted from the data source.
An advantage of the described embodiment of the invention is that the method is not limited the kind of data transformation employed, the number of data sources used, the number of passes of data transformations or the types of presentation. The data transformation process can be complicated, as long as the source node identifiers are passed on after each transformation.
According to the invention in a first aspect, a method of identifying data in a node-based data source is provided, comprising the steps of annotating each node with a unique identifier.
According to the invention in a second aspect, a method of modifying a node-based data source is provided, comprising the steps of associating selected nodes in the data source with identifiers, identifying a node to be modified by reference to its identifier, and modifying the node data.
According to the invention in a third aspect, a data source structured to operate as a node-based data source is provided, wherein at least one node is associated with a unique identifier.
According to the invention in a fourth aspect, a method of annotating a transformed version of a data source is provided, comprising the steps of copying identifiers in the nodes in a data source to corresponding nodes in the transformed version of the data source.
According to the invention in a fifth aspect, an identifier which is capable of uniquely identifying a node in the data source and also a corresponding node in a transformed version of the data source is provided, whereby the node in the data source is mapped to the corresponding node in the transformed version of the data source.
According to the invention in a sixth aspect, a data transformation engine is provided, comprising means of copying identifiers of nodes in the data source and inserting the identifiers into the nodes of the transformed version of the data source, whereby the nodes in the transformed version of the source data are mapped to their corresponding nodes in the source data.
According to the invention in a seventh aspect, an industrial standard of node-based document modification is provided.
According to the invention in an eighth aspect, an industrial standard of identification of nodes in a node-based document is provided.
According to the invention in a ninth aspect, an industrial standard of node-based data transformation is provided.
In general terms, the described embodiments of the invention provide a mechanism that allows a node-based data source, such as an XML document, to be updated from transformed data.
The mechanism comprises ways of preserving a link between a source document(s) and a transformed document, using annotations (or universal identifiers) so that the source of a piece of transformed data is always known. The source location of each piece of data is obtained by the identifiers, even after multiple-passes of sophisticated transformation, and even when the resultant document is a combination of multiple source documents. In contrast to US patent application 20030037303, in order for an update action to be performed, there is no need to generate an inverse transformation script every time the source document is modified or transformed. Furthermore, the mechanism allows update requests to be sent directly to the original data source by means of the identifiers, instead of through an inverse script.
The embodiments described hereafter illustrate how node annotation allows data manipulation in an XML document, such that command procedures and routines may be designed to work on the documents in the same way as scripts are being used to update other types of database such as relational tables or a flat-file database. This imparts data interaction possibilities to XML engines, parsers, editing agents and displays, making XML a more user-friendly form of database structure.
Embodiments of the invention will now described, by way of example, with reference to the accompanying drawings, in which:
A transformation agent 310, on being triggered, runs one or more transformation scripts 311, which may be scripted in XSLT, XQuery or any other XML transformation language. A transformation script 311 determines how an XML document is transformed into another format. The transformation may include data selection and extraction, or combination of data from several XML documents, in ways analogous to queries performed on the tables of a relational database.
An editing agent 320 receives transformed documents 321 produced by the transformation agent 310, and displays them (e.g. in a browser if the transformed documents are HTML documents).
When a transformation of the XML document(s) 301, 302, 303 is triggered, the source document agent 300 firstly annotates each node, i.e. the element tags, the text nodes and so on, in the source XML document(s) with a unique identifier. The transformation agent 310 then receives (at 330) the annotated XML document(s) 301, 302, 303 to perform the transformation/query according to the instructions in the transformation/query script 311, producing a transformed document having data selected from the source document(s) 301, 302, 303. Whether the transformed document is of a different document format, such as HTML, or is also an XML document, the tags defining the elements nodes in the transformed document can be completely different from those in the original XML source documents. Nevertheless, when the transformation agent 310 encloses the extracted text information in tag pairs defined for the transformed document 321, the transformation agent 310 also transfers into the tag pairs the same identifiers which identified the data in the source nodes in the source documents 301, 302, 303. Similarly, the text is also extracted and produced in the transformed document as text nodes, which are also annotated with the same identifiers of their respective source nodes.
The transformed document 321 is then sent (at 331) to the editing agent 320, where the transformed document 321 is displayed (at 332) to a viewer 37 of the document. The editing agent 320 may be an user interface, or is embedded in an user interface, which allows the viewer 37 to interact with the displayed data, such as to perform data updating (data �updating� shall hereafter in this description understood to be inclusive of data replacement, insertion, deletion, copying and so on).
Any modification on the displayed data by the viewer may now be mirrored in the source XML document(s) 301, 302, 303 by means of the identifiers.
An update action (at 341) initiated by the viewer causes the editing agent to send an update request (at 340) directly to the source document agent 300, which performs updating on the source XML document(s) 301, 302, 303. The update request (at 340) is sent along with the identifiers of the nodes on which the viewer 37 has acted.
The source document agent 300, on receiving the update request, has to decide if the update request is allowable, for example, by constraints of security or the schema of the source document, or by applying rules implemented by the programmer. If the source document agent 300 accepts the request, the source document agent 300 uses the node identifiers and data values sent over with the request to locate and update the correct source nodes in the source document(s) 301, 302, 303, be it text nodes, attribute nodes or element nodes formed by tags or tag pairs.
After the source document agent 300 has completed the updating, the updated XML source documents 301, 302, 303 are sent again 330 to the transformation agent 310 to have the same transformation script 311 re-run on the updated source document(s) 301, 302, 303. The newly transformed document 321 is then sent to the edit agent 320 so that the display is refreshed, reflecting the data update. The process repeats as long as the viewer keeps updating the data.
Optionally, the re-transformation on the updated source document(s) 301, 302, 303 may be performed partially, by just re-transforming updated or new nodes. Before re-transformation, nodes which already have been annotated are not annotated again. This ensures that the identifiers persist throughout many transformations. However, new nodes which are inserted into the source documents for the first time are annotated with unique identifiers before re-transformation.
If the update request (at 340) sent to the document agent 300 is not deemed acceptable by the source document agent 300, the source document agent 300 sends a rejection response (at 360) to the editing agent 320. The display will then show a rejection message (at 361) to the viewer 37, preferably also showing the reason for the rejection of the update request.
As mentioned above, the transformation of the source XML document may, instead of a single step transformation, comprises multiple transformations. These may be implemented by executing a number of XSLT and/or XQuery scripts 311 continually, i.e. each XML document transformed by one transformation script 311 is immediately subjected to a further transformation by another transformation script 311, until the final transformed document 321 is sent to the editing agent 320.
Similar to the annotation mechanism described above, the first transformation in a multiple-transformation step triggers the source document agent 300 to annotate the source document(s) 301, 302, 303 with unique node identifiers, which will be inherited by the first transformed document. In transformations subsequent to the first one, identifiers of the nodes in each earlier transform document are in turn inherited by the nodes in the next transformed document. Thus, the nodes in the final multi-transformed document 321 are traceable to the source nodes in the original XML source document(s) 301, 302, 303.
The source document agent 300, therefore, on receiving update requests from the editing agent 320, can carry out updating of the correct nodes in the source document(s) 301, 302, 303, even in response to user action on an extensively multi-transformed document. In other words, the links between the nodes of the source XML document(s) 301, 302, 303 and those of the transformed document 321 are not lost, even if the transformed document 321 is the result of many transformation passes and may have a totally different structure from that of the original source document(s) 301 302 303. Furthermore, even if there are more than one source document, the nodes can still maintain persistent links to the different source documents 301, 302, 303, as the identifiers are unique to each and every source document and node.
A source XML document 40 a has three pieces of data as text nodes, A, B and C. When a transformation is triggered, the nodes are firstly annotated with node identifiers, respectively ID1, ID2 and ID3. The nodes are then subjected to multiple transformations 41, 42, 43 defined in XSLT scripts (alternatively, XQuery or other kind of transformation scripts may be used, or the steps 41, 42, 43 may each use a different type of transformation script).
The transformed document 44 may be another XML document or an HTML document, which is displayed to a viewer having read/write access. The transformations/queries 41, 42, 43 select and extract into the transformed document 44 only the data A and B, which become text nodes 441, 442 in the transformed document. The node 403 of data C having an identifier �ID3� is not selected by the transformation script because, for example, of selection criteria. The identifier �ID1� for the first text node 401 which is data A, is also copied to the transformed document 44 as the identifier of the corresponding text node 441 containing data A. Similarly �ID2� is copied to the transformed document 44 as the identifier of text node 442 of data B.
A viewer (human operator) then modifies node 441 data A to A′, deletes node 442 data B at and inserts new data D (which creates a new un-annotated node 443) in the transformed document 44.
When an update command 451 is sent to the source document agent, the identifier �ID1� of the text node 441, now A′, is also sent to the source document agent with the new data A′, so that the source document agent can update the correct node 401 having the identifier �ID1� to be A′ instead of A.
Acting on the transformed document, the user deletes the text node 442 of data B, identified by �ID2�. When the editing agent sends the deletion request 452 to the source document agent, the source document agent deletes the corresponding source node 402 in the source document 40 identified by the identifier �ID2�, effectively removing data B from the source document 40 b.
As the nodes are identified by the identifiers, the deletion of the nodes 402, 442 containing B, identified by �ID2�, though changing the XML tree structures in the transformed document 44 and the source document 40, does not change the identifier �ID1� of the node of A′. Any source node in the source document is, therefore, still �linked� to the corresponding node in the transformed document by its identifier. In this manner, the updating and modification of data in the source document is effective, independent of inverse transformation scripts, can be effected by actions performed on the transformed document and is regardless of any difference between the structures of the source and transformed document or any changes in the structures.
It is important to note that if the text node inside an element node is deleted, the element node, which is usually formed by an element tag pair, and the element node identifiers remain in the XML document, albeit enclosing no text node. However, when an element node (i.e. the tags defining the element node) is deleted, the entire element node, its identifiers, any text nodes inside the element node, and any child node(s) in the element node are all removed from the XML document, and the XML document structure is changed.
When the data D 443 is sent to the source document agent for insertion, the insertion command cannot be sent with an identifier since D is newly created/inserted in the transformed document and does not have an identifier. Different strategies can be employed to decide where this new text node is placed in the source document 40.
As an illustration of the many possible insertion strategies, the editing agent may be programmed to reference, in the transformed document 44, the sibling or neighbouring node next to which the new node is to be created. For example, the text node 441 of data A having an identifier �ID1� may be referenced (the node 442 containing B having identifier �ID2� is not used as it has been deleted earlier). The editing agent then sends a node insertion/creation request to the source document agent along with the identifier of the sibling node, �ID1�.
When the update command is sent to the source document agent, the source document agent looks for a node having the identifier �ID1� in the source document 40 to position/insert the new source node 404 with reference to node �ID1�. Specifically, whether creating the new node means creating it in a position above or below the reference node 401 in source XML document is left to the developer designing the insertion mechanism to specify. The example of the strategy given here for text nodes is applicable for other processable nodes, such as element nodes.
Another insertion mechanism strategy is one in which the parent node of the new node to be inserted is identified, instead of the sibling node. The source document agent will simply insert a new child node under the corresponding parent node in the source document, next to all the existing child nodes.
Referring to Table 1 as an example, assuming that the XML document is a transformed document, if a viewer wants to add a new book �The Life Of Claude� in the biography section, the editing agent must allow the viewer to insert �The Life Of Claude� into the transformed document (by generating the suitable element tags <bio></bio> to form an element node enclosing the title which is a text node). When sending the update request, the editing agent sends, inter alia, the identifier of the parent node <blography></biography> (the node identifiers are not indicated in Diagram 2, but it is assumed here that the nodes are all annotated for this illustration) to the source document agent, instead of the identifiers any of the sibling element nodes. The source document agent is, in this case, programmed to create a new child element node under the identified parent node, and to insert the title as a text node into the new element node.
The purpose of these examples is not to specify all the updating mechanisms that can be devised, but to show that node identifiers can be used to facilitate the design of such mechanisms. Naturally, the node insertion/creation command sent to the source document agent must specify enough detail in order to let the source document agent knows exactly how and where to act, but other mechanisms will be apparent to one skilled in the art once aware of this disclosure.
Referring now back to
The updated XML source document 40 b is then subjected to the same transformations 41, 42, 43 before being displayed 44 with the updated data. Just before re-transformation, only the new node 404 will be subjected to annotation. Existing nodes, which already have identifiers, are not re-annotated. This ensures persistency in the identifiers.
The update/re-transformation cycle continues until the viewer is satisfied with the modifications.
There is a possibility that a newly added node may not be reflected in the updated display of showing the re-transformed document. This may be due to reasons such as the selection criteria of the transformation/query scripts 41, 42, 43. For example, if the transformation/query scripts 41, 42, 43 include a criterion of selecting only text nodes having a string starting with letter �s�, and if the text in the new node 404 starts with the letter �t�, (or if the updating of an existing text node changes the text therein to one which starts with the letter �t�) then the new data would not be selected during re-transformation, and will not be sent to the editing agent. In such situation, in order to assure the viewer that the node insertion/updating is successful, several strategies may be employed. For example, the editing agent may be programmed to be alerted whenever a new node has been inserted or an existing node is updated, and thus to �look out� for the piece of new data when the display is refreshed. If the new information does not appear after re-transformation, the editing agent may send a confirmation request to the source document agent, which may then invoke a pop-up message to the viewer confirming successful insertion/updating of the new data. Alternatively, the selection criteria of the transformation script 41, 42, 43 may be by-passed for the inserted or updated node, such that the display 44 will show the new data regardless of the selection criteria in the transformation/query scripts 41, 42, 43. A simpler alternative is to program the editing agent to always warn the viewer that a update may not be reflected in the display due to transformation script selection criteria, and that the viewer ought to take other measures to check that the data is inserted, such as running a �select all� script.
If the transformed document is a combination of several source documents, the insertion of nodes will be even more complicated. For example, if the sibling nodes in the transformed document all come from different source documents, rules will have to be programmed into the system such that the editing agent knows which of those nodes (the neighbouring node on the left, right, top or bottom in the XML document) is to be considered a sibling node, and so send the correct identifier as a reference to the source document agent, so that the correct source document may be updated with the new data. Other selection criteria for the sibling node may be used, for example, looking for a node containing some specific text or a number within a certain value range and so on.
A simplified example of how the mechanism of an insertion action may be done by referencing or �anchoring� to a sibling node is shown in
Optionally, the developer may set various constraints on the modifications that can be performed by the source document agent, such as user's access (read/write) rights to an entire source document or even to particular node(s) in the document. Other constraints may come from business logic or XML schema of the source document and so on.
Generally, in order that the transformed documents are annotated with the correct identifiers in the correct nodes, the transformation agents or query agents need to be able to transfer the source node identifiers to the nodes in the transformed documents. Any node in the transformed document which contains editable information from the source document (such as text, elements and attributes) should contain the same identifier from its corresponding source node.
As illustrated in the above examples, the underlying mechanism of the embodiments is in the annotation of the nodes in the XML source document(s) 301, 302, 303 with unique identifiers. The unique source node identifiers can be numerals, text strings or both, or any other data types (such as binary format or binary representation). The node identifiers must be unique for all the nodes in the XML documents that are to be used together in a transformation (preferably even globally unique to all existing XML documents). A node's identifier preferably persists throughout the existence of the node, and even when updating actions performed on neighbouring nodes changes the XML document structure.
Similarly, the node <elmf:5:10/> is traceable to node <elmtE:10/> of Document 5, based on the identifier �5:10�. The name of the elements tags after each transformation does not matter as long as the identifiers persist through transformations.
Specifically, identifiers are persistent through the following updating actions:
Preferably, node identifiers are not recycled. In other words, a newly added node should not re-use any identifiers that have been used by deleted nodes.
Furthermore, nodes in the transformed document should preferably bear only the unique identifiers of the source nodes and should not have their own unique node identifiers generated. That is, a document should not contain unique identifiers of another source document and different unique identifiers of itself at the same time, or the system may be confused or rendered unnecessarily complicated.
Preferably, the identifier syntax is implemented in such a way that the conventional XML data model or info set model is not changed by the annotations, even though each node would now have an associated identifier. In other words, the present mechanisms of XML parsing/processing is not hampered or disturbed by the annotations, so that standard XML parsers may work on annotated XML documents without needing to be modified.
The source document agent preferably has rollback functions built into its design, to enable the update actions on the source documents to be undone when requested. The strategies for implementing rollback functions are well known to the man skilled in the art and will not be discussed further.
In one variation, the source document 40 a, after updating becomes a separate source document 40 b from the original source document 40 a, the original source document 40 a may then be archived.
In a further variation, compression mechanisms may be used to minimise the amount of data communication after re-transformations, for example, using XDiff to find the differences between the XML documents before and after the updates and send only the changed parts to the editing agent for refreshing the display.
As described earlier, due to the passing-on (or inheritance) of the identifiers between transformed documents during a multi-transformation step, the nodes in a final transformed document have the same identifiers as the source nodes. However, in an alternative embodiment, the system may be designed in such a way that transformed documents intermediate in the multi-transformation step have identifiers different from other intermediate transformed documents. This will require, however, a �middle-man� database mapping/tracing the identifiers from each transformation to another, in order to link the nodes between the each intermediate transformed document, the final transformed document and the source document. The design can be used to facility debugging by identifying at which of the several transformation scripts has a problem been caused, when there is any. This also can be used to provide a proxy or firewall interface to protect the nodes in the source documents from direct access for hackers which may use the annotations to trace the data in the source document.
The mechanism described in the embodiments so far relies mainly on three major modules or components: the source document agent, the transformation or query agent, and the editing agent. These modules can be implemented in a distributed intranet or internet environment.
Furthermore, they can be arranged locally or remotely in a distributed environment. Where implemented remotely, the source document agent and the transformation (or query) agent are grouped together in a source document management system, in a �fat-client� arrangement. The source document management system is responsible for storing the source documents and transformation scripts, generating the globally unique source node identifiers, performing transformations or queries and updating the source documents upon requests from the editing agent. The source document management system functions as a server in the distributed environment, having a role which is analogous to a conventional web server combined with the relational database management system. In such a remote network system, the editing agent, which resides on the client side, has a role similar to a conventional web browser but has further functions for data editing interactions. As the client does not need to support complicated transformations such as source document updating and management, this arrangement is advantageous for �thin-client� implementations, such as Kiosks, PDAs and mobile phones. As variations, the client and server can both exist as different processes in a same machine, or in two different machines across an Intranet or the Internet. All that is needed is an implementation of a communication protocol to transmit the transformed documents and the various action requests and feedback between the source management, transformation and editing agents.
Where implemented in a local system, the source document agent, the transform or query agent and the editing agent all run within a same process on the same machine. This may be the implementation choice when the source documents and transform scripts are meant to be available in one system, or when they can be completely or partially downloaded from a server onto a local machine for processing. Therefore, the source document can be edited and updated completely on the client-side without any intermittent server interaction and communication. In the case where the XML documents and transformation scripts are downloaded into the client side for complete processing, upon completion of the updating or other processing, the client resubmits the source documents to the server to completely replace the original source documents. The server's role is therefore simplified to data fetching and to indicate success or failure of the substitution of the source documents, while the client performs all the processing. The communication between the source agents and the editing agent, since now completely within the client machine, can be simplified to using function calls instead of complicated communication protocols.
A further implementation is one which has multi-user concurrent access. This mean that the source documents are not required to be locked during editing, i.e. a source document can be shared by any number of people, or be used by one person working on multiple editing applications. This is possible because user editing actions can be broken down into a sequence of select/insert/delete/update operations on individual node(s) in the source documents, in a way which is very similar to those of SQL statements in a relational database.
At times, there might be a need to carry out a sequence of updating actions which can be packaged into a set of stored procedures in the source document agent (similar to stored procedures in SQL or macros in MSWord). It is left to the developer implementing this invention to design the stored procedure language and syntax. An example of the syntax of an action invoking a stored procedure in the source document agent is given below:
The editing agent may invoke stored procedures by passing parameters. The parameters may contain literal value and the relevant unique source node identifier.
Generally, the well-known CGI (Common Gateway Interface) that supports server-side scripting can be utilised to build the request/response mechanism. There is no limitation on which language or facility is to be used to implement the stored procedures. Existing web related languages like Java, ASP, C#, PHP, or any future action language defined specifically for XML can be used.
The unique node identifiers will now be described in further detail.
In a certain embodiment, an identifier may be made up of three parts: an Originator ID, a Document ID and a Node ID. The composition of the identifier may be varied depending on the preferences of the system programmer, but the identifier should generally impart sufficient uniqueness to the nodes.
The Originator ID identifies the person or originator who created or owns the XML document. In a business environment, the Originator ID may be the domain name or primary IP address of the company or organisation. For large enterprises, the Originator ID may be composed of a hierarchy of IDs, e.g. �Domain ID+Sub-domain ID+Group ID+ . . . +Server ID+User ID� and so on. In an end-user environment, where not every user has a domain name, the Originator ID may even be the originator's email address.
Preferably, the Document ID is a serial number.
Optionally, a separate database may be created to map Document IDs to the file paths or URLs of source documents, by which the source document agent may locate the source document for data updating.
As documents are often moved around in a file system and ported from system to system, it is also preferable that the Document ID is designed in a way that it is persistent despite file transfers between different system, i.e. the IDs are not descriptively tied to the system in which the documents reside.
The last component of the identifier is the Node ID, which is typically a number that is generated incrementally.
The three IDs combined to give a unique identifier. However, depending on the system designer's preference or the resources available to generate unique identifiers, other combinations of identifying components may be used.
An example of how the identifier syntax is extended to standard XML tags and data, in order to allow the unique source node ID to be persistent in source documents, will now be given.
As a first example, the straightforward way is to insert into each node the entire identifier. However, depending on the way an identifier is generated, the identifier may be a very long string. In such cases, since the �Domain ID+Document ID� portion of the identifier is identical for all the nodes in each XML document, instead of repetitively inserting a long identifier in each individual node of the same XML document, the �Domain ID+Document ID� part may be declared in a header of the XML document, while only the Node IDs are inserted into the nodes.
The syntax of the header may be in standard XML declaration syntax. For example, if the Originator ID is �email@example.com�, and the Document ID is �doc123456�, instead of appending both IDs to each and every node in the document, they may be declared in a header in the document:
Each node in the document is then annotated only with Node IDs, which are appended to the XML elements, attributes or processing instructions. The following show nodes in an XML document having Node IDs (in bold) placed after colons:
The XML standard has specified that XML names cannot begin with numerals, therefore the syntax in the above-shown parent node and child nodes (1 and 2) will not confuse the XML parsers. However, in the above example, an escape character, such as an �&� sign is used to indicate an ID for a text. Using this symbol for XML data and comments (child nodes 3 and 4), the annotated document no longer has valid XML syntax. An XML parser to be used on the annotations might have to be modified to recognise and parse the extended syntax.
In an alternative form, the annotation performed by mapping node positions in an XML instruction tags. The XML codes below shows Node IDs in an instruction tag, with a list of Node IDs mapped to child node positions:
The first node shown above lists the Node IDs for each of the child nodes in the document. However, if a node is inserted or deleted, the entire mapping has to be regenerated. An advantage of this type of �header mapping� is that the entire annotated source document remains a valid XML document despite the insertion of the identifiers in the �header� using the syntax of an XML processing instruction. Therefore, existing XML parser and other processors can be used on the source documents without modification. However, such processors should only be granted read-only access, but not write access to the source documents (for example by making the file �read-only�), as they might remove the first node containing the important node-identifier mapping information.
In the two types of annotation steps described above, the former scheme requires the XML parser/application to understand the annotations, so there is no risk of external applications messing up the identifiers inadvertently in some operations. As the annotation is localised, i.e. inserted directly into each node, non-DOM base XML parsers, like SAX, can be implemented which allow parts of the XML tags to be skipped during parsing. In the latter scheme, the syntax of an XML tag that is normally used to contain processing instructions is used to contain the header mapping. In this case, existing XML parsers and processors can be used (for read-only access) without modification.
Variations of the annotation in transformed documents are similar to those described above in source documents.
For a transformed document which is a combination of several source documents, the example below shows how the several Document IDs in the transformed document may be declared using prefixes, in a similar way to how namespaces are declared and referred to in standard XML syntax:
The declaration shows the IDs of two source documents, which were used to form a transformed document, having alias of �1� and �2�. During the annotation step before transformation, the source document agent assigns one of the two aliases, �1� or �2�, to the nodes of each respective document. Each node in the transformed document may therefore contain an alias instead of an entire Source ID, linking each node in the transformed document correctly to one of the source documents.
As shown above, the name of the processing instruction is preferably UniqueSourceDocumentID instead of UniqueDocumentID, to emphasise to the programmer that the identifiers indicated in the tag is of source document(s).
An example of identifier syntax that annotate each individual node is given below:
Example of transformed document:
In an annotation scheme corresponding to the one given earlier for source document annotation, an annotated �header tag�, such as an XML processing instructional node, may be used to map child nodes, by declaring a mapping between nodes and the Node IDs:
Preferably, the method is implemented in such a way that there is no need to amend the structure of the transformation script (e.g. XSLT or XQuery) despite the identifiers. The transformation/query agent (or engine) is simply modified to perform extra steps to transfer the source node identifiers during a transformation/query into the transformed document.
In general, there are two main types of transformation actions which must be accompanied by a transfer of identifiers:
The updating mechanism behind the editing agent 220 the will now be elaborated upon.
An updating request is sent by the editing agent via a communication standard to the source document agent. It is left to the developer implementing the method to define the communication standard and to choose the communication protocol. For example, the communication might be a SOAP/XML protocol that is built on TCP/IP, a remote procedure call or normal function call if the source document agent and editing agent both reside in the same system.
Generally, an update request should contain three specific pieces of information:
Editing interfaces (i.e. user interface) can be broadly classified into two categories: console-based, rich-formatted (in other words WYSWYG).
In a command console type interface, the editing agent presents the transformed document to the user, and provides a command prompt (like MS-DOS prompt) for the user to type in commands. Such a crude interface is very easy to implement, very robust and flexible but has limited user friendliness. Many existing shell scripts such as MSDOS on Windows or other scripting programs on UNIX, can be used to send console commands.
An example of how the syntax of action commands may look is shown below:
Referring now to rich-formatted editing interface, most XML display applications for advance presentation such as markup presentation scripts like XHTML, XSL, SVG, SMIL and MathML are meant to be used for displaying the data and not for user interactive data editing.
In one embodiment of the editing agent, the XML transformed document may contain a new tag element defined to implement user-defined interactivity, such as an <listener> element. The <listener> element may be used to contain and invoke coded routines, such as responding to mouse clicks or other events. The <listener> element may also be attached to or nested inside presentation elements in XHTML, SVG, etc. in order to provide interactive capabilities to otherwise static presentations (W3C's XML Events specification can be referenced to design such event handling elements).
One limitation of the source annotation described so far is that the annotation performed by the source document agent is an �have-all� or �have-none� type, i.e. source annotation is performed on all of source nodes or not performed at all. In a user-rights controlled editing interface, the XML document owner may want to �lock� certain parts of the same document, so that viewers can view those parts of the document without being able to edit them. In this case the XML document administrator author may �switch off� the source annotation functions in the source document agent, or �switch off� the identifier transfer functions in the transformation agent, on the read-only parts of the document. As the resultant transformed document contains no identifiers in the read-only parts, there is no way the editing agent can send effective editing requests to the source document agent on the un-annotated nodes. Only those nodes in the transformed document that has node identifiers support editing actions. Data residing in nodes without identifiers are displayed as �read-only� and cannot be modified since they have no identifiers linking them to the source document. The editing agent may be embedded in a web browser such as Internet Explorer or Netscape. Alternatively, it may be a proprietary user-interactive display programmed by the developer implementing the system. Generally, the display must allow the viewer who has read/write access rights to see and interact with the data in the transformed document underlying the presentation (such as through forms and text boxes in a browser and so on), and to trigger the editing agent to activate the update requests. Any interactive web techniques may be used to facilitate the viewer interaction, for example, Java Applets. The specific presentation format may be defined by a stylesheet, as is common for marked-up language documents.
One variation of the selective node annotation described above is where the selection is done by the transformation/query agent. A fully annotated data source may not have all its identifiers transferred to the transformed version of the data by reason of some criteria in the transformation/query script. Therefore the transformed document has parts which are read only when displayed in a user interface, or by the editing agent.
Three pieces of information that have to be supplied by the editing agent/GUI to the source document agent in an update command are:
The editing agent may be programmed to maintain editing states after transformation. For example, after the source document has been edited and the data is updated and displayed to the user, the focus of the display is returned to the very node/data that had the focus before the updating command issued. In other words, the editing agent has state persistency. The editing agent achieves this by recording the identifiers of the nodes and their display states, such as �selected� or �focused�. Therefore, no matter how the nodes in the result document are updated, rearranged, or restructured, the editing agent maintain state persistency in the display. For example, re-focusing the screen cursor onto the node which last had the focus, or re-positioning a scrollbar of which position is defined by a node as before an updating action and re-transformation (provided that is it has not been deleted). The persistent state information can be sent back to the XML document agent at the end of the editing session and retrieve at the beginning of the next editing session or, alternatively, it can be retained in the editing agent.
An example of serialisation of state using identifiers is shown in the following using mock syntax, with reference to the XML document further below:
A further variation of the embodiment is in using another transformation script(s) to transform and modify transformation scripts currently used on a source XML document. As XSLT is itself an XML document (and XQuery, while not written in XML syntax, has an equivalent syntax i.e. XQueryX), transformation scripts can, therefore, be transformed in the same manner as source documents. The transformation scripts may even be modified �on the fly�, i.e. during an editing session on the source documents. This is possible because this invention does not require the transformation scripts to remain the same during the editing process.
Referring to
Another embodiment of the invention is one which generates source node identifiers that are persistent and unique for only one editing session. Instead of being made up of Originator ID+Document ID+Node ID, the identifier is made up of only Document ID+NodeID. The Originator ID is dropped.
In this case, the source node identifiers are only intended to be used for one editing session and are discarded when the editing session is over. As a result, the source documents can be ported to and from different computers without any restriction, as they do not use system names or addresses as part of their IDs. This can be considered as a scaled-down embodiment of the invention. The advantage of this scaled down embodiment is that the identifiers are simpler to generate and maintain during an editing session.
Although the examples given are addressed in particular to XML documents, these are not restricted in application to only XML documents and can be used on any type of well-defined hierarchical node-based data structure, or marked-up language documents. Furthermore, many non-XML data sources, like HTML, RTF documents can be firstly mapped into an XML equivalent format before editing and then converted back to its original format after editing. The method can also be applied to many other data sources like file system, directory system, Windows registry, relational and object database.
Although this description uses XSLT and XQuery as examples of transformation/query scripts, it is not the intention of the inventor to restrict the use of the teaching with them. There are many other transformation languages with which the mechanisms described herein can be used.
Furthermore, although the terms �transformation� and �query� are usually strictly used with different meanings, referring to the processes of XSLT and XQuery respectively, it is the intention of this specification that they both interchangeably refer to any processes performed on a node-based data source to obtain a set resultant data derived from the data source.
The following example is written based on the use case, �1.1 Use Case �XMP�: Experiences and Examples�, from the specification �XML Query Use Cases� at http://www.w3c.org/TR/xquery-use-cases from W3C. The example is used to illustrate how an XML document is transformed and how the changes made to the transformed document are updated in the source document by the method disclosed in the description of this specification. Two sets of mock XML data below show the prices of some books from two different bookstores, BN and Amazon.
The following are examples of XSLT and XQuery scripts that generate a combined transformed document from the earlier two XML book price documents. After a transformation by either of the scripts, the prices of books from bn.com and amazon.com are selected from the XML documents. The result is formatted in HTML, displaying the titles and prices of books from the two bookstores.
The query expressions/actions which, is executed to create the transformed document, need to be followed by annotation/identifiers transfers from the source documents to the respective nodes in the transformed document. The parts of the codes in the scripts which trigger a transfer of identifiers are highlighted in bold, for example, $b and $a.
In the above example, the user can update both source documents at the same time, as all the XML source documents are annotated and the transformation carry over all the Node IDs. This type of non-selective annotation method is termed �auto source annotation�, as all nodes are automatically annotated regardless of any criterion.
In a more realistic scenario, a manager from BN might want to review the prices of its books in comparison to those of its competitor Amazon. In this case, he is allowed to have read-only rights to the data from Amazon, but is allowed to have read/write rights to the data from BN. The transform or query language therefore needs to be extended to have user selectivity. The following is an example of an extended XSLT or XQuery script with author-specified source annotation, termed �author specific source annotation� in this specification.
In the XQuery script, [$b], which represents data from the bn.com XML document, the brackets indicates to the transformation engine that source node identifiers should be inherited by the corresponding nodes in the transformed document, so that editing by the viewer can take place. The information which is to be extracted from amazon.com is not to be annotated with the identifiers from the source document, and is scripted without a bracket, i.e. $a, so that the transformation engine will not transfer the identifiers.
In the equivalent XSLT script, the line of code which extracts data from the bn.com XML document is indicated with an source-annotate=�yes�, indicating to the transformation engine that source node identifiers should be passed on to the corresponding nodes in the transformed document. The information which is And the resultant HTML page rendered in an HTML browser or editor should look like:
By the embodiments disclosed in the description, a user having read/write access to the data can interact with the rendered HTML document through the editing agent and undertake editing actions by, for example, sending a scripted command through a command console, or through an advance user interface. For example, the user might want to delete the second book and lower the price of the last book.
The request sent to the source agents might, for example, be scripted in a syntax like this through a command console such a MSWindows' command prompt:
In the foregoing script examples, the editable fields will have a coloured background in the HTML display: <td bgcolor=#ccccff>
The transformed or query result with source annotation should look that shown below, where only the bn.com data is annotated with Node IDs.
The result in an HTML browser or editor should look like:
If the bn.com manager wants to carry out the action of changing the bn.com price of the book �Data On The Web�, the requests to the source document agent might have a syntax, without reference to the amazon.com nodes, which looks like:
In general, auto-source annotation (i.e. annotating all nodes) will work in simple cases, and gives backward compatible support for existing XSLT and XQuery scripts because the extra brackets such as [ ]for selective annotation are not needed. Whereas author-specific source annotation will give the viewer finer control over what is editable in the result document.
As described briefly in the description section of this specification, presentation markup scripts like XHTML can be extended to allow author to further specify more editing functions, for example, by a self-defined <listener> tag, or by other interactive scripts like DHTML etc. As an example, the above XSLT script is shown below, further modified to include a self-defined <listener> tag, by which pre-defined updating commands can be send to the source document agent. This avoids having to use the command console to type in update requests, and thus making updating easier through, for example, by mouse clicks on web browsers or other editing interface.
When the user double click within the table row with the identifier 1004 tagged with the <listener> tag, the editing agent may be programmed to construct the following deletion action script (Analogously, if a console-based interface is used, the same script will be typed in by the viewer to be sent to the source document agent):
When the user type over the price within the cell with the identifier 1009, the editing agent is able to construct the update request, in response to �key-down� action on the keyboard, as:
The updated result HTML rendered in some HTML browser or editor should look like:
The following sample code shows the capability of copying new data obtained from another source document into a first source document. The transformed document lists all books and their prices from the bn.com source document, and also shows the corresponding Amazon prices. The Amazon list has a price entry missing for the book �The Economics of Technology and Content for Digital TV�.
Assuming now that the viewer is a manager from Amazon.com without write access to bn.com data (not the bn.com manager anymore, as in the example given earlier), the procedure below shows how the above-mentioned source documents from both bn.com and amazon.com are transformed and combined, and how a data insert (or more accurately according to this illustration, a data copy action) may be effected by using the node identifiers. In this example, the bn.com nodes are now not annotated on transformation, while the amazon.com nodes are.
The rendered result in an HTML browser or editor should look like:
When the amazon.com manager double-clicks on the empty cell, the editing agent is triggered by the code copyPrice( ) in the <listener> tag to send to the source document agent a command to copy the price from the amazon.com to the targeted source node where the copyPrice( ) command is nested in, for example,
As shown in the XML document for bn.com above, 1:1010 is the identifier for the parent element and the child nodes:
The stored procedure or mechanism contained in the �copyPrice( )� command may be scripted for the insertion might look like this:
The above stored procedure shows an example of how a command text, which is triggered by the double-clicking, inserts the tags such as <entry>, <title>, <price> and <review> to enclose the new data, such that the structure is consistent with the sibling nodes. Again, the actual strategy and implementation the insert mechanism and how it is to work is up to the developer. The purpose of the example is to show that source annotation gives the possibility of very specific position identification.
The updated source document in amazon.com should then look like:
Note that the updated source document from amazon.com now has a new price �129.95� for the book the Economic of Technology and Content for Digital TV. The new node is not annotated until the node goes through a cycle of transformation.
It can be envisaged by the skilled man that, as mentioned in the description, a reference may be made to the identifiers of the sibling cells to specifying the position in the amazon.com source document into which the new data should be copied.
The examples show how the annotation system allows data manipulation in an XML document, such that command procedures and routines may be designed to work on the documents to the same effect that query languages are being used to modify tables in other types of database.
Referenced by
Legal Events
Original Image


text:
Ratings based on 1,712 Verified Reviews
They paid and stayed. We double-checked.
4.7 Room cleanliness
4.6 Service & staff
4.6 Room comfort
4.6 Hotel condition
They paid and stayed.
We double-checked.
We double-checked.
for Everyoneby A verified travelerfrom Denver
Beautiful hotel in perfect locationPosted Mar 21, 2015
Pros: The rooms were newly renovated. Great colors, beds, bathrooms, etc. The location of the hotel was wonderful. I felt very safe.
Cons: Not a lot they can do about parking. Once you know how the valet works, it is very quick. Make sure front desk personnel exude friendliness.
Location: Restaurants to visit. Hawksworth and Prohibition at Rosewood hotel, Cactus Club around the corner, and Blue Water Café in Yale Town.
It was my first trip to Vancouver, so choosing a hotel is not always easy. I typically stay in VIP +gold hotels because they provide a wide array of upgrades and benefits. Upon arrival, I was not sure where to park. There was no driveway, so you just have to pull up in front of the hotel along the street and Valet your car. $29 a night, with only a few other parking options close by. I ended up parking in a lot next door the first night, which was very costly. When I checked in, I was not greeted as a VIP member, was not upgraded, and was put on a lower floor facing a street where construction was ongoing. The room, however, was very nice. Large, well appointed, great walk in shower. The hotel is not large. The elevators were not operative at check-in, so we had to take the stairs. The internet service was being upgraded, so it was someone inconsistent coverage. The hotel has an Indian restaurant that is very lovely, with a full service bar. The food was very good. When Expedia received my check-in review, they must have contacted the hotel immediately, because the response of the hotel staff was incredible. I arrived back to my room after working to find a large cheese tray and a bottle of red wine. I then received an apology letter from the manager, telling me that all of my breakfasts and all my valet parking were going to be covered by the hotel. I got to know some of the staff, and really settled into staying there. It ended up leaving a very good taste
by A verified traveler
Terrible hotel avoid at all costPosted Mar 19, 2015
Pros: Nothing, Lot of noise at night unable to sleep
Cons: Staffing behaviour
Location: Nothing just a noisy construction site around and beautiful parking lot view
Expedia refusing to post my Honest Review. We had nightmare staying in this hotel, same blankets never changed. Had to constantly remind to refill supplies. Very rude staff not helpful or friendly. If your tourist avoid at all cost as Hotel has zero information of places to visit.
for Everyoneby A verified traveler
Posted Mar 16, 2015
Great service, and convenient location. Would definitely stay here again.
for Everyoneby A verified travelerfrom Ontario
Posted Mar 10, 2015
Cons: Put a kettle in the room for hot water. The coffee machine water makes your tea take like coffee.
Clean and comfortable room. Big shower area which was great. Staff were very helpful and friendly.
for Everyoneby A verified travelerfrom Kamloops, BC
Greek Revival DecorPosted Mar 10, 2015
Pros: Great room service breakfast menu! Baggage storage, if you have checked out but still want to go shopping before getting your car. Thank for that!
Cons: Don't think this requires improvement, just found it very odd. There is a Master switch at the front door which will turn off ALL the lights at once.
Location: Walk to everything. Starbucks, shopping mall, cafes, etc. Perfection.
Clean room, comfortable bed in own room with door. Black out curtains. Pull-out couch could accommodate two more. Small selection of snacks and alcoholic beverages in room. Nice to see an extra blanket available in the room as well as the one on the pull-out couch.
for Everyoneby A verified travelerfrom Vancouver Island
Posted Mar 10, 2015
Pros: Location and charm.
Location: Convention centre was our destination so it was close. Cactus Club nearby was convenient for a late night bite.
Great service in the lobby, front desk and bellmen/valets. Friendly and thoughtful ie: giving four of us cold water bottles for our car ride to the ferry. Very genuine, not with a handout for a tip.
for Everyoneby A verified traveler
Business tripPosted Mar 8, 2015
Great proximity to convention center! Very friendly and helpful staff. Most important for me... very clean and comfortable mattress and pillows.
for Everyoneby A verified travelerfrom Winnipeg, MB
Comfortable, central locationPosted Mar 3, 2015
Pros: Convenient location and comfort.
Cons: In-room Wi-Fi internet could be faster... In the lobby and the restaurant, I find myself switching to ShawOpen instead of the hotel Wi-Fi.
Location: Pacific Centre. Hawksworth. Bella Gelateria. Vancouver Art Gallery. The location is so central, you can walk to all the cool places and great food.
Good service. Convenient location. Super nice room.
for Everyoneby A verified traveler
Great location and excellent front desk staffPosted Feb 26, 2015
Pros: Location and Staff
Location: Excellent
Good Hotel Great staff ..........................
for Everyoneby A verified traveler
Posted Feb 25, 2015
I feel very good in my hotel. The room is clearly, and the room look like very beautiful. I like this style of hotel. If I go to Vancouver, I will choice it again.

subset: commoncrawl


text:
Available formats: epub mobi pdf rtf lrf pdb txt html
Done a lot of cool things in my time... Was a disc jockey back when radio stations played 45 rpm records, did a stint as the news director of a state-wide radio network in Alaska, and logged more than a few years as a talk show host... Been both a deputy sheriff and a city cop... Seen murders and suicides, known good guys and bad guys, saints and sinners and stone cold killers... and been loved by some wonderful women.
Back in my really younger days, too full of Kerouac and Hemingway, (I think of it as my Nick Adams period now, after, you know, Papa's Adventures of a Young Man) I was On the Road for a few years, a guitar on my shoulder, sleeping under bridges and in parks and on the subway, thumbing rides, and hopping a freight train or two along the way just to say I had. Never could play the guitar worth a damn, but carrying the thing around got me rides, and into beach parties, and laid more than once.
I don't really know where I'm from. Grew up in Montana and Wyoming, but spent a lot of time in LA back when LA was cool, and the funny thing is, when I was in Wyoming I always felt like I was from LA, and when I was in LA, I felt like I was from Wyoming... I've always been real into western history, though, (livin' in Tombstone, Arizona now, go figure) and through some combination of direction and DNA, it was no doubt my grandmother who gave me that.
My grandmother the ranch cook. I was a Casper boy who spent my summers on whatever ranch she happened to be working -- the ZN, the Big Creek, the A Bar A -- and man, it's vivid like yesterday... (My little feet sticking straight out on the front seat of a battered old pickup, and she's saying, "Over there, just over those hills. Hole-in-the-Wall. Remember me tellin' you about Butch Cassidy?..." Or, another time, another place: "Bosler... It was right around here where Tom Horn was pickin' off rustlers for the Swan Land and Cattle Company...") For better or worse, those are character building moments, and memories like that don't fade much. Not ever.
Maybe, as Toby Keith once said, I Should've Been a Cowboy... Well, who ever knows? I guess that's just one of the roads untraveled for me. But you know, thinking about it, I do know where I'm from... I'm from Wyoming.
So I'm in Tombstone now with Sam the cat. We walk the haunted streets together, and I try to keep him safe from the coyotes and the javelinas that come prowling at night. I write, and I'm with the Tombstone Marshal's Office, and there's a lot of weird but cool synchronicity in that, don't you think?


text:
The fifty best concert photos of the winter
The crowd at Life In Color Tour featuring Borgore and more at Balch Fieldhouse, CU Boulder, 2/16/13
Christopher Morgan
Winter is officially in the books. Spring is finally here, and we've got a whole new batch of shows to look forward to. Before we forge ahead, we thought we take a look back at all the shows we made it out to in the past few months and single out the best moments. Turns out, there were a quite a few highlights. Continue on for the fifty best concert photos of winter.
See also:
- Previews: The fifty best concerts of the spring
- Reviews: The thirty best concerts of 2012
- Photos: The thirty best concert photos of the fall
Get the Music Newsletter
Keep your thumb on the local music scene with music features, additional online music listings and show picks. We'll also send special ticket offers and music promotions available only to our Music Newsletter subscribers.
Sponsor Content


text:
One lakh houses for EWS every year: Kamal Nath
Top Stories
- Nitish Kumar's JD(U) recognised as principal opposition party in Bihar, BJP protests
- SC extends Setalvad's interim bail and asks her lawyer Kapil Sibal not to 'act smart'
- Aero India Show: Stunt planes collide in mid-air, pilots safe
- Swine flu deaths soar to 663, number of cases cross 10,000
- Maratha Mandir brings down curtains on Shah Rukh Khan's DDLJ
Urban Development Minister Kamal Nath has said that the Delhi Development Authority will build one lakh houses for the economically weaker sections (EWS) every year.
He made this announcement at a meeting of the consultative committee attached to the Ministry of Urban Development.
He said around 40 lakh people in Delhi live in unauthorised colonies and to prevent further growth of slum clusters, the government regularised 917 unauthorised colonies this financial year.
He said Delhi cannot expand towards its borders and, therefore, has to grow vertically. And this is why land use pattern is very important, he said.
Referring to the Delhi Master Plan 202, Kamal Nath said: "It is a dynamic document and must be reviewed periodically. A mid-term review for the current Master Plan was done recently. So far, 4,300 suggestions have been received.''
The need to focus on certain other areas, especially revenue earning, was also discussed at the meeting. There were suggestions that DDA build and rent out 'baraat ghars' (marriage halls). It was also suggested that the DDA build barracks and hutments for migrant labourers in Delhi so that urban slums are not created.


text:
Tag Archives: future
Hopefulness at the General Assembly
As a rabbi of an innovative global organization, it is important for me not just to be in my office but to also be on the road learning from others. That means I try to attend a handful of conferences each year—and today I'm a first-time attendee at the Jewish Federation of North America's General Assembly, known in shorthand as "the GA." It's a conference for volunteer and professional leaders of Jewish Federations and those with an interest in Jewish philanthropy.
At events like this, my hopes are that I will make connections to new friends and colleagues, that I will learn some new tools, that I will leave with just as many questions as answers, and that I will have a sense of optimism about what is possible in the Jewish community.
When I was flipping through the list of sessions, I realized there are two ways to view them, one more positive than the other.
There's a long-standing tradition that Jewish telegrams were easy to recognize because they would say simply, "letter to follow. Begin worrying." And, it is easy to read through a list of session topics at a conference like this, and to begin panicking: How will we fundraise? What will Israel's future look like? How will we engage teens/young adults/aging adults/interfaith families/fill-in-the-blank? What will we do about rising anti-Semitism in Europe? How do we balance collectivism and individualism? Is Jewish education working or not?
Some people answer those questions with doom-and-gloom answers. But I don't think that's what this conference is about (otherwise I wouldn't be here!). Conferences like this work when those in the room confront the realities of Jewish life and then figure out how to embrace opportunities for what could be rather than bemoan what is.
While there is some truth that worrying is part of the Jewish historical experience, it is also the case that celebration has long been an affirmation of a positive Jewish identity. We are a people of happiness and joy, laughter and humor. We are a people of hope.
Rabbi Lord Jonathan Sacks, a speaker at this conference, once said that "Judaism is humanity's faith in the future tense; the Jewish voice is the voice of inextinguishable hope."
Being at a conference with thousands of people who care about Jewish life and want to celebrate it – this gives me much hope. My telegram (now a tweet) from my time at the GA will say: email to follow, no need to worry—we are a people of hope.
To watch my Rosh Hashanah sermon on which this blog post is loosely based, please click here.
Like this post? Get the latest in MyJewishLearning's weekly blogs newsletter.
Note: The opinions expressed here are the personal views of the author. All comments on MyJewishLearning are moderated. Any comment that is offensive or inappropriate will be removed. Privacy Policy
Taking The Plunge
It was January 2007, almost exactly six years ago. I was sitting in my office, reviewing a dense corporate document retention proposal, when I realized it was time for a career change. I had questioned whether I wanted to remain a lawyer for several years. On the one hand, the law firms where I practiced treated us like indentured servants. We worked extremely long hours, were yelled at, and spent most of our time toiling away at menial tasks like reviewing boxes of emails or proofreading our bosses' work. On the other hand, the pay was great and the risk was low. All we had to do was sacrifice our time and our pride and we could do quite well. For years, the financial benefits of the job and the uncertainty about what else I might want to do held me in check. But by 2007, the drudgery of the work and the sense of how meaningless it felt became too much for me. I decided that the risk of switching careers—even to something as dramatic as becoming a rabbi—was worth it.
This dilemma of accepting an unpalatable status quo or taking a risk on an uncertain but potentially transformative new direction is basically what the Israelites confront in Parashat B'shalah. The Israelites have just fled from Egypt and have journeyed as far as the Sea of Reeds when God rouses Pharaoh to chase after them. God is looking for the big finish to the Exodus drama, a climactic battle in which God can once and for all establish supremacy for all to see (Exodus 14:4). The Israelites, however, are not amused. In fact, they are terrified. Whatever faith in God they might have developed from experiencing the ten plagues quickly evaporates in the face of charging chariots and alarming battle cries. They beg Moses to let them return to their former lives of slavery in Egypt. But Moses tells them to have faith, and God, through Moses, parts the waters of the sea so that the Israelites can pass through to the other side. We all know what happens next: the Israelites make it safely across the sea, and once they get to the other side, God causes the waters to crash down upon the Egyptians who are in hot pursuit, drowning them in the sea.
In a fascinating commentary, though, our Sages did not just assume that the Israelites had the courage to march into the parted sea. Even though this event, the crossing of the Sea of Reeds, would become a seminal moment in Jewish history which we recount twice a day in our liturgy (in the Mi Chamocha prayer), the Talmud (Tractate Sotah 36b-37a) depicts the Israelites as being hesitant to take the plunge:
Rabbi Yehudah said: When the Israelites stood by the Red Sea, the tribes strove with one another. This tribe said. "I'm not going into the sea first." And another tribe said, "I'm not going into the sea first." [Finally,] Nachshon the son of Amminadav jumped and descended into the sea first.
Rabbi Yehuda reflects how we often feel when facing a life-altering challenge. The fear of making change can often be paralyzing. Inertia is a powerful force, as is the psychological comfort of predictability, no matter how unpleasant the predictable may be. We can—and do—come up with a multitude of justifications for staying right where we are. We are conditioned, both culturally and biologically, not to go into the sea first. But Rabbi Yehuda's account also expresses the truth that it only takes one leap, one chance, one moment of action, and our whole world can change.
We each face these crossroads in life. For some, it might be whether to remain in a relationship that has gone stale or whether to endure the pain and anguish of ending the relationship with the hope of finding a better one. For others, like myself, it might be whether to remain in a job that lacks fulfillment but provides a steady paycheck, or to pursue a dream job that might not work out.
We even experience this crossroads at national levels. As the Israeli election on January 22 showed, Israel is almost perfectly split between center-left and right-ultra Orthodox parties (each bloc received approximately 60 out of the 120 seats in Israel's parliament). Israeli leaders, in picking a new government, will have to choose between retaining the status quo coalition of the past few years or forming a new coalition that embraces socioeconomic reform, equal treatment of Haredi and Hiloni Israelis, and an engaged peace process. Will a Nachshon ben Amminadav emerge to lead Israel into a new, dynamic, and possibly redemptive future, or will Israel's leadership remain entrenched on the shore, arguing among themselves and unwilling to take the first pivotal step forward?
Change is always hard. We yearn for stability, structure, and continuity in our lives. Yet the wisdom of our tradition is that God will support us if we are willing to take the plunge into uncertainty. The narrative of the Israelites standing at the Sea of Reeds offers us more than just an historical/mythical account of our people's origins. It empathizes with the difficulties we face, today, between taking risks on an unknown but potentially meaningful future versus remaining mired in an unpleasant, yet known, present. And it offers us hope if we are only bold enough to claim our own redemptive path.
After the Israelites realize their freedom from the Egyptians, they break out into raucous celebration. The people unite in a triumphant and jubilant song, known as Shirat ha-Yam, the Song of the Sea, which we recount each year during the Torah reading for Parashat Beshallah. May each of us be blessed with the courage to follow our own paths of meaning in life. And may our decisions enable us to sing with joy about the lives we create for ourselves and our people.
Note: The opinions expressed here are the personal views of the author. All comments on MyJewishLearning are moderated. Any comment that is offensive or inappropriate will be removed. Privacy Policy
Yom Kippur: All-Souls Day
Do people change? As human beings, are we not the sum of our unique genetic make-up and the equally unique combination of experiences, good and bad, that have brought us to this present moment? And, if the above is the case, than what is the point of the Yom Kippur fast? What is the point of this long day of introspection – the synagogue liturgy peppered with calls for Teshuvah (repentance or return) – if in the end we are who we are, and that's it?
Some will answer that the meaning of Yom Kippur, this Day of Atonement, also called a Shabbat Shabbaton (the Sabbath of all Sabbaths) is to bring about contrition in our short-comings and strive to make the next year better. There might be something to it. It's good to try. My view of Judaism has a focus of human perfecting, getting incrementally better and better, rather than the unattainable goal of perfection.
Nonetheless, isn't it ridiculous to expect that this will be there year you finally get it right? Didn't I really try last year? And, in fact, what expectation is there that this year will be better than last if the dates for next Yom Kippur are already set on the calendar?
I could no longer expect to really change who I am than I could radically alter my own genetic code or build a time machine that would take me back and tinker with the specific events of my past, especially my early childhood, both good and bad, that shape my personality. After all, Nature and Nurture have shaped me into who I am, and, well, that is that. Isn't it?
I think not. All of the above misses a powerful trope in Judaism, namely that, while we have free-will, making all of our own choices, nonetheless, our soul has a trajectory.
According to the Talmud (Niddah 30b), every soul is specifically chosen to live the life of every specific person. Every soul is guided by an angel who teaches the soul everything it will need to know in the world. Then, upon birth, the angel touches the upper lip, leaving a tiny dent, confounding speech, and a bit of amnesia. The soul cannot simply come into this world from the realm of God, Infinity, and mystery. As a rabbi I have come to understand my calling less at teaching people Torah, but rather helping them uncovering what they're soul already knows. I call it Holy Remembering. It accounts for those moments of epiphany when our life's events align, life makes sense, when disparate pieces of knowledge show us a clearer lens with which to see the world. "I thought I knew it, but now I understand".
The challenge of Yom Kippur is to consider your soul's trajectory.
What are the moments of your life, good and bad alike, that have shaped you? What career path you are meant to take, the people you are meant to love, the causes you are meant to champion, the good deeds you were chosen to accomplish—these are all very specific things that you were meant to do; you were designed for these specific things. People often try to turn away from doing the thing they're meant to do, or are most naturally gifted at. Some events were no doubt simple chance. There is a bit of randomness in the world, but there is order too. Your soul knows what it needs to do in this world, it knows too the experiences you need to help it fulfill its calling. What if your soul chose your parents? What if your soul chose to lead you to those powerful turning-points in your life?
Your soul cast "you" in the role of (your name here) to accomplish some very important things. Sometimes we fight against what our soul wants for us – in those moments, life is a bit of a drag, we feel trapped by circumstance, powerless to overcome our lot in life. The Bible is filled with characters who run away from their soul's trajectory, Moses feigns a speech impediment, and Jonah, whom we read about on Yom Kippur and whose soul's trajectory was aimed at the big city of Niniveh, avoids his calling and finds himself inside the bely of a whale instead. But, when we understand, when we honor our soul's calling, our life has flow – the abundance of life becomes obvious to us, as if it has always been there but now we feel it.
So, Yom Kippur… Introspection – yes, definitely. But, not simply to uncover your particular foibles. You know what they are already and so does God. Rather, ask, "In all those moments, at those touch-points of my life, good and bad, was my soul guiding me to experiences that I needed to have, to help me fulfill my soul's calling?" "What kind of a caretaker have I been to my soul's journey."
The message of the holiday can be: Your soul has chosen you for a reason. Your soul needs you (imperfections and all) to carry it along a unique path, that only you can carry it. Yom Kippur is not really about the past, where you've been, but rather, the future, where all those moments have been leading you to. This Yom Kippur, and throughout this new Jewish year, ask, "What roles or tasks am I running away from via distraction that my soul wants me to pursue?"
Note: The opinions expressed here are the personal views of the author. All comments on MyJewishLearning are moderated. Any comment that is offensive or inappropriate will be removed. Privacy Policy
A Data-Driven Eulogy for a Data-Driven Life
"Humans make errors. We make errors of fact and errors of judgment. We have blind spots in our field of vision and gaps in our stream of attention. Sometimes we can't even answer the simplest questions. Where was I last week at this time? How long have I had this pain in my knee? How much money do I typically spend in a day?"
Thus begins Gary Wolf's New York Times Magazine article "The Data-Driven Life." As our lives converge with machines, data, in mass amounts, becomes the new wisdom.
Here is a bit of satire for those of us who approach that future with a bit of trepidation.
…The Lord is my Shepherd, I have zero needs.
We gather here in a moment of great sadness to mourn the passing of someone close to us all. The actuaries were right. What can we say – the numbers tell the story.
In health: His numbers were not so good. His blood pressure was 140 over 90 with a resting heart-rate of 72. His cholesterol was 330, with a frighteningly low HDL of 19. As many of you know, chromosomally he did have a few recessive abnormalities on chromosomal pairs 4, 23, and 24. But did they do him in? Unlikely, everyone could see that his BMI was well over 33!
…Yea, though I walk through the Valley of Asymptote Limit of Negative One, I will fear no evil, for You are with me.
His high school GPA was 3.7 (3's and 4's for his AP scores), 2110 for his SAT score, 3.4 at a 3rd tiered college, no GRE score to speak of (this technical mystery will be corrected in time for the obituary). He graduated without honors from a 2nd tired Graduate School. Such was his education.
… Your staff and Your rod, they comfort me.
Of course his consumer habits have been readily searchable. He shopped mostly at Mega Shopping Grocery. He accounted for approximately $95 of weekly average purchase they with a slightly elevated purchase quotient in the salted Snack aisle. Google reports that his interests were roughly evenly split between on-line fantasy games, sports, especially Indonesian Cricket, and Googles' own World News Digest. Sadly, he had three outstanding bids for collectible Disney watches on eBay. He would have won. Nonetheless, those watches have already been sent to the next highest bidder. His digital life is otherwise unremarkable, with the exception of a single visit to a porn site. Google Notes suggest that it is statistically possible that he reached the site by searching for Morgan Spurlock's documentary film "Super Size Me," and by then clicking their search feature "Feeling Lucky."
…You set before me a table against my enemies. You anoint my head with oil. My cup overflows.
He was married for 34.6 years and had 2 girls and 1 boy. His favorite song was Bob Seger's "Feel Like a Number." His combined FICO score was 678. The family has asked that in lieu of flowers, kindly make a digi-donatation to their favorite cause, IRS Approved Non-Profit Mobil Code XH35G. That code number is now being broadcast to your phones and also appears on the screen above the casket. Please use this moment of silence to transact now.
… Surely goodness and mercy will follow me all the days of my life, as I dwell in the Infinite Loop of the Lord forever.
So it is that we bury Social Security number 456-89-9987. Let me add, unorthodox as it may be in our data-driven life, and at such an intimate setting no less, that he was my closest friend. I will always remember him. Bit by byte, he will be missed.
Yitgadal V'itgadash Shemei Rabbah …
Note: The opinions expressed here are the personal views of the author. All comments on MyJewishLearning are moderated. Any comment that is offensive or inappropriate will be removed. Privacy Policy