Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Namespaces keys order #64

Open
eduardocp opened this issue Oct 22, 2019 · 7 comments
Open

Namespaces keys order #64

eduardocp opened this issue Oct 22, 2019 · 7 comments

Comments

@eduardocp
Copy link

Why namespaces key and value has the key as the uri of namespace instead of the real key on xml?

Ex.:

var namespaces = <String, String>{
    'soap' : 'http://www.w3.org/2003/05/soap-envelope/',
};
var builder = new xml.XmlBuilder();
builder.processing('xml', 'version="1.0"');
builder.element('soap:Envelop', namespaces: namespaces, nest: () { });

var result = builder.build();

produces:

<?xml version="1.0"?><soap:Envelop xmlns:http://schemas.xmlsoap.org/soap/envelope/="soap"/>
@renggli
Copy link
Owner

renggli commented Oct 23, 2019

You need to define the namespaces like so:

  final namespaces = {
    'http://www.w3.org/2003/05/soap-envelope/': 'soap' ,
  };

See the documentation.

@renggli renggli closed this as completed Oct 23, 2019
@eduardocp
Copy link
Author

Yes, I saw the documentation. Maybe I expressed myself badly. I wanted to understand why this is so, since it is more intuitive (in my opinion) that the key is alias not uri.

@renggli renggli reopened this Oct 24, 2019
@renggli
Copy link
Owner

renggli commented Oct 24, 2019

I see, this is not very obvious. I am trying to remember why the key-values are ordered like this? Other implementations also seem to do it this way, i.e. http://effbot.org/zone/element-namespaces.htm. Probably this has to do with the underlying implementation, but maybe there could be better ways of exposing this to users?

@rspilker
Copy link

rspilker commented Jan 6, 2022

I think the main reason is that a namespace is defined by a uri, therefore it seems a good idea to make it a key.

A namespace is not required to have an alias (prefix). Still points to a key with a null value.

But a namespace can have zero or more aliases (not zero or one alias).

Making the alias the key would solve the or more problem, but not the zero case.

Since it is very unlikely that a single element would use multiple aliases for a certain namespace, having the namespace as a key makes more sense.

I think instead of using a `Map<String,String?>', a separate type would have been a better option.

@rspilker
Copy link

rspilker commented Jan 6, 2022

Hmm, the signature is not Map<String,String?) but Map<String,String>. However, you could always call void namespace(String uri, [String? prefix]) instead.

@renggli
Copy link
Owner

renggli commented Jan 6, 2022

Yeah, the signature should be Map<String, String?> for consistency.

@renggli
Copy link
Owner

renggli commented Jan 6, 2022

Fixed this with f460492.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants