host noNamespaceSchemaLocation schemas online

[fooman]

It would be great if all the xml schemas (referenced via xsi:noNamespaceSchemaLocation) could be hosted online and versioned. Until developer RC this could be named draft.

[SchumacherFM]

What is the downside of supplying the noNamespaceSchemaLocation with the code instead of online?

I think this depends on your dev env: For each validation (on save or so) it would download the .xsd from the remote source which takes quite a while.
Now in PHPStorm it uses the local file and makes validating fast and is also versioned ;-)

[fooman]

When a Mage2 extension is installed via composer the code ends up in the vendor directory with a different folder structure which makes the relative location incorrect.

Currently the xsd locations are in different parts of Magento2 which makes working with it unintuitive.

I usually keep extension code separate from the Magento2 codebase (think modman, et al) - the extension code then has a different relative path. Again something an online permanent address would help with.

I also believe having 1 online location of the file will make it easier to develop, ie you can just copy it from a core module, another extension, an online tutorial without having to worry about relative paths which at multiple levels deep gets hard to read and easy to make a mistake.

versioning

this was in the hope of having less versions, ie we currently have 1 standard for every commit of Magento2. So my hope is that one standard gets worked out for each of the file formats and then stick to it so that is applicable across a lot of different Magento2 versions (hopefully with very little to no changes over time)

local offline development

this is of course a consideration but I think can be worked around if you really are working offline most of the time. I have to hit validate manually in PhpStorm.

[alankent]

The use of relative paths is not ideal, agreed. We were considering between hosting online vs using say a URN. Regardless, PHP Storm can be configured to point to the local schema files. Versioning makes sense as well - that is, putting a version number into the URI (whether local or hosted). An advantage of local hosting (not having it available online) is avoiding a potential performance problem when tools download the file unexpectedly due to misconfiguration.

Right now my personal preference is to version the URLs, but not host online. Instead we provide instructions how to set up php Storm so the xml schemas are read from local files (for speed) and versioned (can help with migration and possibly support better backwards compatibility as we can detect the version of the file from the url).

Currently modules can introduce dtds, which does mean we need to think of a good approach to work out file path given a urn. Eg. Put module name into urn. All doable, just needs thinking through a bit more to make it flexible for the future.

[SchumacherFM]

Works fine. So you can map the URI of raw.github... to your local xsd file in the correct version. PHP Storm does not download the file. Performance problem solved. Correct versioning problem shifted to the developer ;-)

[alankent]

To be clear in case any confusion, we don't want to use the github version number. We want the version number to only change if the schema changes between releases.

[fooman]

👍

[cmuench]

@alankent why not a real URI for all the XSD files? With every new "standard" you can place a new file on your server.

[alankent]

It is an approach (and we are discussing it internally), but you do need to be a bit careful.

1. You need to be careful of a DDoS attack of hundreds of thousands of sites and developers downloading the XSD files.
2. You need to make sure production does not do downloads as it could slow down production sites.
3. You need to make sure 3rd party modules that introduce their own XSD files have a good strategy too.

But these are solvable problems (and may already be solved). What do others think? Do people prefer "real" URLs and we host the URLs somewhere public? We would put a version number in the URL and publish new ones each time it changes. (We can still ship a copy inside the distribution as well.)

[piotrekkaminski]

Thank you for your submission.

We recently made some changes to the way we process GitHub submissions to more quickly identify and respond to core code issues.

Feature Requests and Improvements should now be submitted to the new Magento 2 Feature Requests and Improvements forum (see details here).

We are closing this GitHub ticket and have moved your request to the new forum.