Re: Example XML chunk for enum-services [IANA #171390]

Hello Michelle,

thanks for the suggested XML chunk. Generally, is there any suggestion
on namespace/schema of that XML? i'm well aware that this is right now a
chunk, but defining a namespace would allow to define a schema.

more comments inline.


> <record>

I'd rather suggest to name that "top" element "<enumservice>" - "record"
seems too generic to me.

>   <class>Protocol-based</class>
>   <type>foo</type>
>   <subtype>bar</subtype>

Fine with me. Those elements could be restricted fairly well in a schema
- type as well as subtype are limited to 32 alpha/digit/dash characters.


class would be a choice of possible values.

>   <scheme>bar</scheme>
>   <scheme>bars</scheme>

I would rather call that "urischeme", but "scheme" is good enough, i
think.

>   <spec>
>     This Enumservice indicates that the resource identified can be
>     addressed by the associated URI in order to foo the bar. [...]
>   </spec>

hmm.. the naming of the element somehow would clash with the
"specification reference" listed below. maybe rename that to
"functionalspec" to make it clear?

[see below for the "further info" element on content issue..]

>   <security>See <xref type="rfc" data="rfc9999"/>, Section 
> 7.</security>

fine with me.

>   <usage>COMMON</usage>

Fine, would be easy to restrict it to the allowed values

>   <xref type="rfc" data="rfc9999"/>

I think that the reference to the specification deserves to be
highlighted, i would suggest using something like the "security" element
outlined above, for example:

<specdoc>See <xref ...> </specdoc>

BTW, how would one reference documents of other SDOs? like in XML2RFC
templates?

>   <xref type="person" data="John_Doe"/>
>   <xref type="person" data="Jane_Dale"/>

Fine with me - my question is what the relation between person objects
and enumservices would be - would the person be a seperate object, or
simple embedded in the Enumservice registration XML document?

>   <info>Further information free text...</info>

There is an issue here, wich also applies to the "spec" element above -
we have Enumservices registrations which use "markup" in those fields -
bullet lists, paragraphs, etc.

If we just allow plaintext here (which would be the simplest version) we
would lose existing information.

However, personally i think that such information should rather be
contained in the registration document itself rather than the registry
entry - 

> </record>
> 
> <person id="John_Doe">
>   <name>John Doe</name>
>   <org>ACME Corp.</org>
>   <uri>mailto:[email protected]</uri>
>   <updated>2008-10-10</updated>
> </person>
> <person id="Jane_Dale">
>   <name>Jane Dale</name>
>   <org>ACME Corp.</org>
>   <uri>mailto:[email protected]</uri>
>   <updated>2008-10-10</updated>
> </person>
> 
> Fields having "N/A" as value should instead simply be omitted in XML.
> 
> We did notice in the document it says "Note: You MUST NOT put 
> email addresses in the authors field of an IANA Registration."
> I would prefer a "Registrant" and a "Registrant E-mail".  
> Then a separate "Specification" where it points to the 
> document and that is where a person could get the contact 
> info for the authors.
> What are your thoughts on that?  Is it possible to have the 
> document reflect those?

I *think* the idea of not allowing an email address in the "author"
field was that this information was supposed to be taken from the
specification document's "authors" section. 

I'm happy to include the "person" information that you have outlined
above, especially if there are other registries that make use of that
scheme as well.

Any comments?

Alex