This is a static archive of the previous Open Grid Forum GridForge content management system saved from host forge.ogf.org file /sf/discussion/do/listPosts/projects.ggf-editor/discussion.cp_standardized_xml_namespaces.minor_issues at Thu, 03 Nov 2022 23:20:05 GMT SourceForge : Post

Project Home

Tracker

Documents

Tasks

Source Code

Discussions

File Releases

Wiki

Project Admin
Project: Editor     Discussion > CP:Standardized XML Namespaces > Minor issues > List of Posts
Forum Topic - Minor issues: (2 Items)
View:  as 
 
 
Minor issues
Mostly very good spec (short is good!) but there are a few minor issues:

Section 2.4 should be subsection of 2.3

Section 2.6 should indicate that the domain part be a domain name owned by GGF, even in extensions. Note that this form 
of extension is also not really compatible with the rules of 2.13; the rules on DNS names are considerably more 
restrictive (ASCII letters, digits, hyphens and periods as separators, as defined in RFC 1035). I'd suggest recommending
 against DNS names that require punycoding (RFC 3492) to be usable.

Examples in section 2.8 need to indicate that /jsdl is the correct form of /jsdl-wg (and ditto for /bes and /ogsa-bes)

Section 2.10 should indicate that we're using the Gregorian calendar and similarly, section 2.11 should indicate that as
 well and that January is month 01 (duh!). These are the interpretations from ISO 8601 (though perhaps YYYY-MM would be 
a better format, necessitating a coalescing of the two version terms? Or even using the year plus ISO week number, in 
either split or merged form?) The major alternative is to use date terms out of RFC 822 section 5 (however separated).
Re: Minor issues
Hi Donal, thank ou for your comments.

> Section 2.4 should be subsection of 2.3 

Yes, I will change this.

> Section 2.6 should indicate that the domain part be a domain name
> owned by GGF, even in extensions. Note that this form of extension
> is also not really compatible with the rules of 2.13; the rules on DNS
> names are considerably more restrictive (ASCII letters, digits, hyphens
> and periods as separators, as defined in RFC 1035). I'd suggest 
> recommending against DNS names that require punycoding (RFC 3492)
> to be usable. 

If you are interpreting the character strings generated according to this specification as URLs, then you are most 
certainly right. 

But the primary goal of this specification is to generate simple character strings that are eventually used in XML 
documents, hence subject to the XML document's encoding declaration (usually UTF-8 anyway). It is just some (more or 
less lucky) coincidence that the character strings defined here *look like* URLs.

For GGF to use this specification as a certainly useful basis to offer an online schema repository, GFSG may decide to 
profile this specification and and restrict certain elements to conform to restrictions in place for Internet domain 
names.

> Examples in section 2.8 need to indicate that /jsdl is the correct form 
> of /jsdl-wg (and ditto for /bes and /ogsa-bes)

Yes indeed. Thanks for pointing this out.

> Section 2.10 should indicate that we're using the Gregorian calendar
> and similarly, section 2.11 should indicate that as well and that January
> is month 01 (duh!). These are the interpretations from ISO 8601
> (though perhaps YYYY-MM would be a better format, necessitating a
> coalescing of the two version terms? Or even using the year plus ISO
> week number, in either split or merged form?) The major alternative is
> to use date terms out of RFC 822 section 5 (however separated). 

I've been thinking about this, and the indication that the Gregorian Calendar is used is certainly necessary to be added
. I will change the specification accordingly.
Considering the proposal to use a combination of year and week number, a year sometimes has 52 weeks, sometines 53 - so 
a year is not always a fixed multiple of one week. On the other hand, a year always consists of 12 months. 
In general, after pondering the proposed alternatives I am inclined to stick with the current proposal, not because it 
is difficult to implement or change, but simply because the current draft is already widely adopted (which is a good 
sign in itself). A change here would force all GGF working groups to sweep their documents and fix the change.

In any case, thanks for your comments!

 
 


The Open Grid Forum Contact Webmaster | Report a problem | GridForge Help
This is a static archive of the previous Open Grid Forum GridForge content management system saved from host forge.ogf.org file /sf/discussion/do/listPosts/projects.ggf-editor/discussion.cp_standardized_xml_namespaces.minor_issues at Thu, 03 Nov 2022 23:20:06 GMT