I'm editing a lot of XML files using Liquid XML, I can associate a schema with the document by adding a schemaLocation attribute, but this is not practical as I have lots of files and I can't leave the attribute in as the upstream processor doesn't like it!
Is their a way I can associate a schema with a group of files?
There are a few ways to associate XSD schemas with an XML document.
Schema Location Attributes
If the XML Document contains a schema location attributes (xsi:noNamespaceSchemaLocation or xsi:schemaLocation attributes), then the schemas pointed to are loaded and used for validation and intellisense.
Namespace
The namespaces declared in the XML file are used to lookup schemas from the Schema Library. If a namespace in your XML file matches an entry in the schema library then all the schemas for that entry are loaded. You can also add your own entries to the Schema Library (more about this below).
Manually associating schemas
You can manually associate schemas with your XML File. Use the "Xml Document to Schema Mappings" form to select existing entires in the Schema Library, or "Add Schema file" to select a single XSD file to associate with the XML document. These settings are then remembered then next time the XML file is opened. This is particularly useful if your XML file does not contain a target namespace, as automatic matching is therefore not possible.
Manually associating a schema with an XML File
You can control the schemas that are associated with your XML File using the "Xml Document to Schema Mappings" form.
The form show all the schemas that have been added to the Schema Library. At the top of the list are the schemas that have been found in your XML document (ie via xsi:noNamespaceSchemaLocation or xsi:schemaLocation attributes).
Checked - Explicitly included schema. The schema is used regardless of whether the namespaces appear in the XML document. This can be useful when associating schemas with XML documents that do not contain any namespace information.
Unchecked - Explicitly exclude schema. The schema will not be used regardless of whether its namespaces match the XML Document. This is useful when you have several versions of the same schema, and they all have the same namespace, or where the schema is so large intellisense slows down the XML Editor to an unacceptable degree.
Indeterminate - Automatic schema selection. If the namespace in the schema entry match the ones in your XML file then this entry will be used.
This is the default state for all entries.
Adding your own Schema Library Entry
If you have a set of schemas that are not in the standards library you can add your own entry.
Note you can add several schema files that may not necessarily be associated with each other, say for example FIXML contains annotations that in your documents contain XHTML, you could also add the XHTML schema. If you did this it would be a good idea to de-select the XHTML namespaces from the trigger namespaces listed (so this standard is not used when an XHTML document is opened, only when a FIXML document is opened).
And Finally the Answer
If your XML documents are all in a given namespace your best bet is to create a Schema Library Entry. This will be automatically associated with any XML documents that contain that namespace, so you will get validation and intellisense automatically.
Related
I am trying to find the relationship cardinality details from the .twb file but not able to find it.
From the .twbx tableau application On unzipping it a .twb file is generated which contains the metadata about the application in xml format even though it has a relationships tag but no cardinality information is obtained in that.Where can I find them in the xml structure
It seems simple, but I'm not sure I understand the difference. Both metadata files and vardefs contain field definitions and both ultimately point to Sugarfields
So what it's the difference between the 2 when it comes to field definitions?
The difference betwene metadata and vardefs is,
metadata is a simple table structure definition so sugarcrm knows what fields/tables to add to the database on repair&rebuild.
Vardefs are field-definitions inside modules, also resulting in db fields in the table of the module, but vardefs can't exist without a module, metadata can (only) exist without a module.
I was able to define a custom programming language in Enterprise Architect with custom data types by navigating to Project > Settings > Code Engineering Datatypes.... When I create a MDG file, I have the option to include the programming language definition, and as far as I can tell, this is working - at least, in a new project that uses the MDG file, I can see the programming language.
Now I would like to have the same behavior for DBMS and database datatypes defined through Project > Settings > Database Datatypes.... From my tests, I get the impression that these types are not automatically included in the MDG file, and I haven't found a trivial way to include them. Is there a way to add the database datatypes to the MDG file as well? If not, is there a way to achieve the same result through the automation interface, e. g. by writing an add-in that creates the DBMS and the associated datatypes?
Going the MDG Technology way, the answer appears to be no. It's possible to trick EA (11) into exporting DB types in an MDG Technology, but even if they're in there, they will be ignored in projects that use the MDG Technology.
DB types and code engineering (or, sometimes, "programming language") datatypes are both stored in EA's t_datatypes table. The same product name can be used for both a programming language and a DB engine.
It looks like the MDG Technology Wizard scans this table looking for rows with "Code" in the Type column during the setup (Code Modules wizard page), but when the time comes to write the actual datatypes into the output file, it retrieves all rows with the specified ProductName.
This means that if you create a DB product and populate it with a set of datatypes, and then create a programming language product with the same name but just a single dummy datatype, your DB types will be included in the MDG Technology XML file along with the dummy type.
However, it appears that while the regular properties dialog (for classes etc) checks the loaded MDG Technologies in addition to the t_datatypes table in order to populate the Language drop-down list, the specialized properties dialog for database tables does not check the MDG Technologies when populating the corresponding Database drop-down. So even though the datatypes are in the file, you can't use them.
Going the Add-In route, the answer is yes.
Have your Add-In respond to the EA_FileOpen event and check the Repository.Datatypes collection to see if your DB types are installed and if not, add them.
You don't actually need to write an Add-In if you don't want, you can write an in-EA script. The only thing an Add-In can do that scripts can't is respond to events (which is why those are listed in the Add-In Model section of the help file). So with a script you would have to trigger the function manually.
There is also an API to manage project's reference data of which code / DB datatypes is one category, but it only gives you control of some of the categories (eg requirement types and constraint types), and the datatype category is not one of them.
I have to migrate my custom system to typo3 version 6.2 but I did not find any database diagram(design/schema) of typo3. Would be great if someone can help. Thank you.
In a TYPO3 installation without extensions, there are not many tables that will interest you. Interesting tables are
pages and pages_language_overlay: Pages and their translations.
tt_content: Content, translations are in the same table.
sys_language: Define available languages. For pages with only a default language it can stay empty.
sys_domain: Define Domains under which a site is available. For single domain installations it can be left empty.
sys_file_reference: References to files, which are stored in table sys_files. The table sys_files will be automatically filled when you put files into the fileadmin folder.
fe_users and fe_groups: Frontend users and groups.
The other tables are either caching tables (names start with cf_) or are mostly used internally (most tables having names starting with sys_).
In some of the tables, especially in pages and tt_content, there are deprecated fields.
The usage of some fields depends on the actual TYPO3 setup. For example, the text of a content element from tt_content could be stored in the field bodytext, or in the field pi_flexform. So the question how to import your data depends on your setup.
For further information have a look at the official docs: https://docs.typo3.org/typo3cms/CoreApiReference/latest/ApiOverview/Database/DatabaseStructure/Index.html
I don't have a diagram either, but this note is too long for a comment:
Most M:N relationships (e.g. users & groups) are handled with foreign key attributes stored as comma-separated entries inside table cells, inside rows of the parent table. Of course, this nonatomic way of storing data violates first-normal form of database-table design.
However, some newer extensions do rely on bridge tables. In typo3, this is called an M:M relation, and some tables have a naming corresponding convention, e.g. tt_news_cat_mm, linking news-messages with news-categories.
I am learning to use Sparx Enterprise Architect for requirements management. I am wondering, what is the best practice, or any practice to describe CSV file structure (i.e. header names and their types) that will be imported by designed system?
Do you use taggeed values, or simply just "Notes" area? Or maybe just link sample csv file, but then, how to include it in printed documentation?
Thank you for advice!
UML is, of course, not good at describing structures such as CSV formats. You can create classes with attributes "col_1", "col_2", etc, but the simplest way is probably to add a linked document to the requirement (right-click and select Create Linked Document).
The linked document can be included in a generated document quite easily. In the template editor, simply select the Linked Document node under the Element node.
These linked documents are stored inside the EA project. They are RTF, so they are very limited compared to other formats, but they support tables and other basic formatting, which is usually enough for requirement details.