Subject: [netmod] metadata in JSON

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 28 Jul 2014 11:08:43 +0200

Hi,

as I mentioned in Toronto, the mapping of XML attributes to JSON cannot
represent namespaces of attributes, which is IMO a serious deficiency.

Now, since YANG 1.1 issue Y33 (add "attribute" statement) was shot DEAD,
we need to find another way for attribute namespace encoding.

Peter Saint-Andre once proposed a generic method in the expired draft

http://tools.ietf.org/html/draft-saintandre-json-namespaces-00

For example,

<flag xmlns:ex="http://example.com" ex:foo="a">true</flag>

would be mapped as follows:

"flag": true,
"@flag": {
  "{http://example.com}foo": "a"
}

This is of course not very nice as namespace URIs will often be longer
than in this example. Any other suggestions?

Thanks, Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 28 Jul 2014 11:55:01 +0200

> we need to find another way for attribute namespace encoding.

What has the JSON encoding of namespaces for attributes todo with Y33?
Why can we not make the namespace encoding we have for leafs make work
for attributes as well?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 28 Jul 2014 12:27:29 +0200

> Why can we not make the namespace encoding we have for leafs make work

Y33 proposed the top-level "attribute" statement for defining *global*
attributes. Such a definition would make an association between the
attribute and YANG module, and then, indeed, we could use the same
namespace encoding as for other data nodes. For example, with

module exattr {
    namespace "http://example.com";
    prefix "ex";
    attribute foo {
        description "...";
        type string;
    }
}

my example would become

"flag": true,
"@flag": {
  "exattr:foo": "a"
}

Lada

---

From: Andy Bierman <[email-masked]>
Date: Mon, 28 Jul 2014 03:47:06 -0700

>     namespace "http://example.com";
The definition of any attribute used within RESTCONF needs to pick a
string that will be used as the module name.

The YANG to JSON mapping can simply say that a module name is
assigned to an attribute somehow.  The module name and attribute
semantics do not need to be defined in YANG.

Lada
> > /js

Andy

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 28 Jul 2014 14:06:30 +0200

> semantics do not need to be defined in YANG.

But then, IMO, the cleanest way is to make this explicit by using the “attribute” statement which

- assigns the attribute to a module,
- also assigns the namespace URI and recommended prefix for XML encoding,
- defines a datatype for the attribute, which may occasionally be useful.

I’d like to emphasize that Y33 was only about global attributes, i.e. it doesn’t attempt to make attributes into regular data nodes, so the following would NOT be possible:

leaf flag {
    attribute foo {…}
    …
}

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 28 Jul 2014 14:13:28 +0200

On Mon, Jul 28, 2014 at 02:06:30PM +0200, Ladislav Lhotka wrote:
 
> I’d like to emphasize that Y33 was only about global attributes, i.e. it doesn’t attempt to make attributes into regular data nodes, so the following would NOT be possible:

I can counter argue that easily: If we do not do Y33, then there are
no attributes and hence there is no need to encode them in JSON. Move
the whole attribute encoding text into a non-normative appendix and we
are done.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 28 Jul 2014 14:19:44 +0200

> the whole attribute encoding text into a non-normative appendix and we

Well, it needn’t be there at all because YANG doesn’t model attributes. Normative or not, without means for representing an attribute’s namespace it doesn’t make sense to have it there.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Mon, 28 Jul 2014 05:33:06 -0700

On Mon, Jul 28, 2014 at 5:13 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> > But then, IMO, the cleanest way is to make this explicit by using the
> "attribute" statement which
> >
> > I'd like to emphasize that Y33 was only about global attributes, i.e. it
> doesn't attempt to make attributes into regular data nodes, so the
> following would NOT be possible:
> >
> > leaf flag {
> >     attribute foo {...}
> >     ...
> > }
>
Several people want to support attributes in the RESTCONF protocol messages.
Martin came up with a solution that works and we already agreed to use it
in RESTCONF.

I agree there does not need to be a YANG definition for the attributes
used in RESTCONF protocol messages.  The attribute definition could
be in an XSD. The description annotation can specify the string to use
for the module name, for encoding as a qualified attribute in RESTCONF.
(The YANG insert attributes are just defined in text, not even an XSD).

There is no need to define any attributes at all in YANG data model content.
It we do that, then it will be abused.  I want to support protocol layer
attributes like
with-defaults (report-all-tagged) or conditional enablement (enabled).
The protocol spec should define protocol attributes, not the data modeling
language.

I have said before many times -- a mapping from YANG to JSON is somewhat
useless because we don't sent JSON across the wire. We send protocol
messages
encoded in JSON.  We need a mapping that allows entire protocol messages to
be encoded,
not just the YANG content layer.

Andy

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 28 Jul 2014 14:36:30 +0200

> Well, it needn’t be there at all because YANG doesn’t model attributes. Normative or not, without means for representing an attribute’s namespace it doesn’t make sense to have it there.

Yes. We can remove the text completely. That said, I got told that
implementations sometimes use attributes and hence it might be useful
to have agreement on some convention to support that.

Checking the RESTCONF specification, I find this in Section 3.5:

   The RESTCONF protocol needs to retrieve the same meta-data that is
   used in the NETCONF protocol.  Information about default leafs, last-
   modified timestamps, etc. are commonly used to annotate
   representations of the datastore contents.  This meta-data is not
   defined in the YANG schema because it applies to the datastore, and
   is common across all data nodes.

   This information is encoded as attributes in XML.  JSON encoding of
   meta-data is defined in [I-D.lhotka-netmod-json].

Checking RFC 6241, I find:

   error-message:  Contains a string suitable for human display that
      describes the error condition.  This element will not be present
      if no appropriate message is provided for a particular error
      condition.  This element SHOULD include an "xml:lang" attribute as
      defined in [W3C.REC-xml-20001006] and discussed in [RFC3470].

Checking the RESTCONF specification, it seems the error-message
becomes part of an ietf-restconf:errors object. Does it carry the
xml:lang attribute forward?

/js

---

From: Andy Bierman <[email-masked]>
Date: Mon, 28 Jul 2014 05:48:53 -0700

On Mon, Jul 28, 2014 at 5:36 AM, Juergen Schoenwaelder <
[email-masked]> wrote:

> > On 28 Jul 2014, at 14:13, Juergen Schoenwaelder <
> > Well, it needn't be there at all because YANG doesn't model attributes.
> Normative or not, without means for representing an attribute's namespace
> it doesn't make sense to have it there.
> >
>
I think this could be considered an open issue because Lada did not
want to include it (but I do).  I know the name has "xml" in it, and
so does "anyxml".  NETCONF does not allowed XML mixed mode
content. RESTCONF needs the same disclaimer.

In NETCONF-EX there is an "encoding" capability excahnge.  Somebody might
even
be crazy enough to encode NETCONF in JSON, just to cut the msg size in half.
(But NETCONF is only for giant routers, so why do that! :-)

/js

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 28 Jul 2014 15:10:27 +0200

On 28 Jul 2014, at 14:33, Andy Bierman <[email-masked]> wrote:

> 
> 
> 
> On Mon, Jul 28, 2014 at 5:13 AM, Juergen Schoenwaelder <[email-masked]> wrote:

This doesn’t necessarily mean it has to be part of draft-ietf-netmod-yang-json.

> for the module name, for encoding as a qualified attribute in RESTCONF.

To serve this purpose for standard attributes such as “active” , the module name should be registered with IANA, and I am not sure it was intended to allow for registrations of non-existing modules. If so, then I am fine with that.

> It we do that, then it will be abused.  I want to support protocol layer attributes like
> The protocol spec should define protocol attributes, not the data modeling language.

OK, so then the protocol can also specify their ad hoc encoding in JSON. I’ve been saying this all the time but you and Martin insisted on having the generic attribute mapping in the yang-json I-D. I should have resisted. :-)

> useless because we don't sent JSON across the wire. We send protocol messages
> encoded in JSON.  We need a mapping that allows entire protocol messages to be encoded,

In fact, YANG only defines the schema and constraints for datastores, where RPCs and notifications can be considered special types of datastores.

It is only for historical reasons that RFC 6020 also includes specification for the encoding of NETCONF messages. RESTCONF (or I2RS or whatever) protocol messages are not included there and, consequently, every new protocol has to specify how the datastore contents and their fragments are mapped to various protocol messages, be it XML or JSON. I think this is fully appropriate. In fact, if we want to make YANG 1.1 less NETCONF-centric, the NETCONF-specific parts should be put into a separate document.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Mon, 28 Jul 2014 06:32:20 -0700

On Mon, Jul 28, 2014 at 6:10 AM, Ladislav Lhotka <[email-masked]> wrote:

> > > I'd like to emphasize that Y33 was only about global attributes, i.e.
> it doesn't attempt to make attributes into regular data nodes, so the
> This doesn't necessarily mean it has to be part of
> draft-ietf-netmod-yang-json.
>
>
It was in the RESTCONF draft, and then we agreed to move it to the JSON
draft.
I guess we really need an issue tracker ASAP because we keep debating the
same issues over and over.

> To serve this purpose for standard attributes such as "active" , the
> module name should be registered with IANA, and I am not sure it was
> intended to allow for registrations of non-existing modules. If so, then I
> am fine with that.
>
>
The YANG attributes (insert, value, key) are in YANG XML namespace
(URI in sec. 5.3.1). This is not a YANG module namespace.

> OK, so then the protocol can also specify their ad hoc encoding in JSON.
> I've been saying this all the time but you and Martin insisted on having
> the generic attribute mapping in the yang-json I-D. I should have resisted.
> :-)
>

The WG already decided to move this text from RESTCONF to the JSON draft.
So what new arguments are you presenting that justify re-opening this issue?

> In fact, YANG only defines the schema and constraints for datastores,
> where RPCs and notifications can be considered special types of datastores.
>
>
IMO there is no such architectural purity here.
The intent is to support an RPC message model and event notification
messages.

> It is only for historical reasons that RFC 6020 also includes
> specification for the encoding of NETCONF messages. RESTCONF (or I2RS or
> whatever) protocol messages are not included there and, consequently, every
> new protocol has to specify how the datastore contents and their fragments
> are mapped to various protocol messages, be it XML or JSON. I think this is
> fully appropriate. In fact, if we want to make YANG 1.1 less
> NETCONF-centric, the NETCONF-specific parts should be put into a separate
> document.
>
> Lada
>
> >
> >
> >
> > Andy
> >
>

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 28 Jul 2014 16:17:15 +0200

On 28 Jul 2014, at 15:32, Andy Bierman <[email-masked]> wrote:

> It was in the RESTCONF draft, and then we agreed to move it to the JSON draft.

How does RESTCONF encode these attributes in JSON?

> The WG already decided to move this text from RESTCONF to the JSON draft.

I haven’t seen any evidence of this being a WG decision. That’s why the first question in my presentation in Toronto was

   Is this draft an appropriate place for defining metadata encoding in JSON?

and I didn’t notice any consensus about this in the room. In the relevant thread

http://www.ietf.org/mail-archive/web/netmod/current/msg09338.html

only you and Martin wanted to have the mapping in the yang-json draft but Martin also said (http://www.ietf.org/mail-archive/web/netmod/current/msg09350.html):

       Maybe the original JSON mapping idea is the only one that works; i.e.,
       map pure YANG data to JSON.  No meta data.  A protocol that needs meta
       data should not use JSON; use XML instead.

> So what new arguments are you presenting that justify re-opening this issue?

The lack of namespace mapping.

Lada

> The intent is to support an RPC message model and event notification messages.
>

---

From: Andy Bierman <[email-masked]>
Date: Mon, 28 Jul 2014 07:54:45 -0700

On Mon, Jul 28, 2014 at 7:17 AM, Ladislav Lhotka <[email-masked]> wrote:

> > > > But then, IMO, the cleanest way is to make this explicit by using
> the "attribute" statement which
> > > >
> > > > I'd like to emphasize that Y33 was only about global attributes,
> i.e. it doesn't attempt to make attributes into regular data nodes, so the

So if it was moved to a different document, that would be OK?
Vendors will implement the standard if there is one.  If not,
the features vendors need will get implemented anyway,
but proprietary schemes.

> intended to allow for registrations of non-existing modules. If so, then I

The protocol spec that defines the datastore meta-data will define it so
it works with that protocol.

> How does RESTCONF encode these attributes in JSON?
They are query parameters in the URL or YANG Patch is used instead

> I haven't seen any evidence of this being a WG decision. That's why the
> first question in my presentation in Toronto was
>
> and I didn't notice any consensus about this in the room. In the relevant
> thread
>
> only you and Martin wanted to have the mapping in the yang-json draft but
> Martin also said (
> http://www.ietf.org/mail-archive/web/netmod/current/msg09350.html):
>
The RFC that defines any protocol attributes for RESTCONF can define a YANG
module
if they want, so there is a module name to specify in the ad-hoc or XSD
text.

RFC 6020bis can easily register a standard module name
that goes with the YANG XML namespace if the insert attributes
ever need to be supported (and there is desire to make sure YANG
is not XML-specific).  Your draft just needs to say
that the field contains a YANG module name.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 28 Jul 2014 17:31:56 +0200

> the features vendors need will get implemented anyway,

As far as the yang-json draft is concerned, this would be OK. Attributes aren’t YANG data nodes.

...

> The RFC that defines any protocol attributes for RESTCONF can define a YANG module
> if they want, so there is a module name to specify in the ad-hoc or XSD text. 
> 

It should also specify how the association between an attribute and a module is established, if the module says nothing about it, or even doesn’t exist at all. How do you find out which attributes are associated with a given module? Can anybody add a new attribute to an existing module at any time? 

I really fail to see how a module-top-level “attribute” statement could possibly encourage misuse of attributes, I’d say it’s rather the opposite. Having an explicit attribute definition with a description and subject to revision rules of YANG modules etc. is IMO much better than implicit and hand-waving associations.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 30 Jul 2014 12:55:55 +0200

> that the field contains a YANG module name.

I do agree that using a module name as the namespace identifier is the
best option, but I need to figure out how the assignment of an attribute
to a module is supposed to work.

Let's say RFC XXXX defines a few attributes, and this RFC also registers
a module name "foo-attributes". My questions:

1. Will the module foo-attributes exist or not?

2. What if RFC XXXX is updated by YYYY, some new attributes are added,
   or the semantics of the existing ones are changed? If the server
   advertises the foo-attributes module, how can the client know whether
   it means the XXXX or YYYY version?

3. Could an independent RFC define new attributes and state they also
   belong to foo-attributes?

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 30 Jul 2014 13:08:28 +0200

>    belong to foo-attributes?

I am not sure that module names are the best choice - at least they
make conversions between XML representation and JSON representation
more difficult since you need to know how to make the namespace
identifiers.

That said, I do think that for the JSON mapping document, it is enough
to say how things are encoded. I think it is not the job of the
document to define the whole process around attributes. I do
understand that this makes the solution somewhat incomplete but it
allows us to finish this document now and to move forward.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 30 Jul 2014 13:12:12 +0200

> more difficult since you need to know how to make the namespace

Perhaps the document should actually discuss this somewhere and be
explicit that transformations need to be aware of the data models to
work correctly. Having this clearly documented might help. (I
personally think it would have been really really nicer if this is not
required but surely the encoding requires to know what the YANG data
types are of the leafs.)

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 30 Jul 2014 14:50:27 +0200

> I am not sure that module names are the best choice - at least they

Well, the alternatives (i.e. either using full URI as a part of attribute name or mimicking somehow the XML prefix-URI mapping) are really anti-JSON, and they would also be confusing in the context of the YANG-JSON mapping.

> more difficult since you need to know how to make the namespace

This is already done for YANG data nodes anyway.

> document to define the whole process around attributes. I do

Saying that the namespace identifier is a module name without giving any guidelines about how to choose this module would be rather weird and won’t help implementors.

> allows us to finish this document now and to move forward.

That is my priority, too.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 30 Jul 2014 15:02:47 +0200

> work correctly. Having this clearly documented might help. (I

Sec. 1 in draft-ietf-netmod-yang-json-00 says:

   1.  The translation is driven by a concrete YANG data model and uses
       information about data types to achieve better results than
       generic XML-JSON translation procedures.

This should also mention the namespace-to-module-name mapping.

> required but surely the encoding requires to know what the YANG data

Pyang’s jsonxsl plugin demonstrates that the schema-aware translation can be effectively automated. The prefix-URI mapping that’s used in XML proved to be problematic.  

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 30 Jul 2014 15:04:14 +0200

> Well, the alternatives (i.e. either using full URI as a part of attribute name or mimicking somehow the XML prefix-URI mapping) are really anti-JSON, and they would also be confusing in the context…

Not sure what defines anti-JSON, i.e. why using a namespace URI would
violate something that a module name does not violate.

> This is already done for YANG data nodes anyway.

Yes, I understand that. Even if we make this assumption, I think it
would be good to spell this out explicitely right upfront so that
people know that a translation without knowledge of data models was
not a goal of the design. I am sure people will try to do this and we
better make sure everybody understands upfront that this won't work.

> Saying that the namespace identifier is a module name without giving any guidelines about how to choose this module would be rather weird and won’t help implementors.

I have been told implementors already do some of this and this is why
we should worry about attribute encoding. Now you are saying this does
not help implementors. Sounds like a contradiction? I think you are
looking for interoperability of attributes. Well, as long as we have
no mechanism to really define them, they are by definition
non-interoperable. So why then define their encoding? Well, it gives
us at least an interoperable way to communicate attributes, which may
be better than non-interoperable solutions to encode attributes.

> That is my priority, too.

Good. So what speaks against saying that if attribute names clash and
if attributes are scoped by a module name, then the encoding is XYZ?
This allows future specifications to define further rules as needed.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 30 Jul 2014 15:11:43 +0200

> Pyang’s jsonxsl plugin demonstrates that the schema-aware translation can be effectively automated. The prefix-URI mapping that’s used in XML proved to be problematic.  

This was not my concern. Think about a gateway translating between
NETCONF (XML encoding) and RESTCONF (JSON encoding). This gateway now
needs to know all data models for the data passing through the
gateway. So the problem is making sure you always have the schema, not
the schema-aware translation. 

I know your answer will be you can always grab the schema as long as
you do online translation. So here is another example: Think about a
tool that is storing data in one of the presentations (say XML) and
then the data is processed by a tool that likes to have the data in a
different representation (say JSON). Now you need to track the schema
for each stored data set to be able to do the conversion.

Again, it is fine with me if the WG agrees this is just how it is. I
just want to make sure this is well understood and clearly documented.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 30 Jul 2014 17:53:30 +0200

> violate something that a module name does not violate.

The URIs we use for YANG modules are 40-50 characters long and they would have to be used with every occurrence of such an attribute. However, if there was consensus on doing it this way, I won’t object.

“Backporting” the heavyweight XML features to JSON really begs the question of why to use JSON instead of XML in the first place.

> better make sure everybody understands upfront that this won't work.

I think it is quite clearly said in the introduction.

> I have been told implementors already do some of this and this is why

Unfortunately, RESTCONF I-D gives no concrete information about encoding and namespace of metadata that are “commonly used”.

> looking for interoperability of attributes. Well, as long as we have

Most XML attributes carry no namespace because they are tightly bound to their parent elements in the schema. YANG doesn’t have this kind of attributes though.

On the other hand, global attributes that can be attached anywhere, such as xml:lang, are almost always defined with a namespace, and presumably it will also be the case with attributes defined in the future for use with YANG data. I don’t think that simply dropping the namespace information is a good idea.

> if attributes are scoped by a module name, then the encoding is XYZ?

I thought YANG 1.1 was a good opportunity to decide about how to do this scoping, provided that standard attributes are really needed.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 31 Jul 2014 07:52:01 +0200

> I thought YANG 1.1 was a good opportunity to decide about how to do this scoping, provided that standard attributes are really needed.

Lets keep the discussion focused on the JSON document. Are you OK with
the proposal to add text that attribute names may be scoped?

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 31 Jul 2014 08:19:39 +0200

> I think it is quite clearly said in the introduction.

I do not think so. The text says:

   3.  XML namespaces specified in the data model are mapped to
       namespaces of JSON objects.  However, explicit namespace
       identifiers are rarely needed in JSON text.

Item 1. is about types and item 3. does not clearly say that URIs (XML
namespaces) are mapped to JSON qualified names that use module names
and that this mapping requires knowledge of the YANG module name to
URI relationship.

Another nit:

   The namespace identifier MUST be used for local names that are
   ambiguous, i.e., whenever the data model permits a sibling data node
   with the same local name.  Otherwise, the namespace identifier is
   OPTIONAL.

YANG 'permits' sibling data nodes with the same local name almost
everywhere through augments. Perhaps you wanted to say "... whenever
sibling data nodes exist that have the same local name." I am also not
sure the rules are clear in situations like this:

module a {
  container top {
    container a {
      leaf name;
      leaf value;
    }
  }
}

module b {
  import a;
  augment '/a:top' {
    container a {
      leaf name;
    }
  }
}

I assume name does not require qualification in the following,
correct?

{
  "top": {
    "b:a": {
      "name": "foo";
    }
  }
}

I assume this is illegal (even though it is not ambiguous)?

{
  "top": {
    "a": {
      "b:name": "foo";
    }
  }
}

But then this would be legal, no? I mean a box not implementing module
b would generate this.

{
  "top": {
    "a": {
      "name": "foo";
    }
  }
}

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 31 Jul 2014 10:49:07 +0200

> the proposal to add text that attribute names may be scoped?

Yes, if there is no other choice. It is unclear what “scoped” means.

Lada

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 31 Jul 2014 11:22:40 +0200

> and that this mapping requires knowledge of the YANG module name to

Yes, the text needs improvement but even now there can be little doubt that the translation requires knowledge of the data model. I will make sure it is absolutely clear.

> sibling data nodes exist that have the same local name." I am also not

I think the current formulation is correct, it means in other words “… whenever the schema permits a sibling data node with the same local name."

> I assume name does not require qualification in the following,

Correct, the two “name” leafs are not siblings in the data model (their parent nodes are not the same).

> I assume this is illegal (even though it is not ambiguous)?

Yes, it is illegal - the “a” containers are ambiguous in the sense of the paragraph you cited.

> But then this would be legal, no? I mean a box not implementing module

Yes, in this case its data model consists only of module “a” and there is no ambiguity.
 
>      "name": "foo";

Do you think the text should be changed/expanded or more examples added?

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 31 Jul 2014 12:18:45 +0200

On Thu, Jul 31, 2014 at 11:22:40AM +0200, Ladislav Lhotka wrote:
> I think the current formulation is correct, it means in other words
> “… whenever the schema permits a sibling data node with the same
> local name."

I still think the text is somewhat confusing. In the example I posted,
module a does not know about any sibling data node with the same local
name, still it permits such a node to be defined in a different
module. The ambiguity is perhaps coming from "the data model" and
"permits".

> Do you think the text should be changed/expanded or more examples

Either could work. Writing the text is likely more difficult than
writing the examples but the best would be good text accompanied 
with examples. ;-)

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 31 Jul 2014 12:24:46 +0200

On 31 Jul 2014, at 12:18, Juergen Schoenwaelder <[email-masked]> wrote:

> "permits”.

Would “the data model defines” be better?

> writing the examples but the best would be good text accompanied 

OK, will try.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 31 Jul 2014 14:20:48 +0200

> Would “the data model defines” be better?

Yes.

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 31 Jul 2014 14:22:00 +0200

> Yes, if there is no other choice. It is unclear what “scoped” means.

Scoped by a namespace, such as 'namespace:identifier'.

/js