[glue-wg] Some questions... [WAS: choosing XML Document structure for GLUE 2.0 rendering]

[Paul Millar]

Hi Sergio, rest-of-list,

On Tuesday 11 December 2007 06:43:49 Sergio Andreozzi wrote:
> > http://www.doodle.ch/participation.html?pollId=sg4v8qvy3h4h6d9t
>
> this is a gentle reminder for the voting about XML document structure.
> Please, express your opinion by December, 12. If you choose for option
> 3. or 6. you are invited to send your alternative as well.

Sorry I'm new to this discussion, but the current proposals don't make much 
sense to me.  Looking at the discussion[1] further confuses me.  At the risk 
of disrupting this process, I'd like to ask some questions...

[1] 
http://forge.ogf.org/sf/wiki/do/viewPage/projects.glue-wg/wiki/GLUE2XMLSchema

First, I see that one of the rules is ID is an element.  Why is this?  It 
seems we're reinventing the wheel here: XML already defines the concept of an 
ID (see [2] and [3]), which is used in related standards ([4], [5], etc...).  
Why not just use this?

[2]   http://www.w3.org/TR/2006/REC-xml11-20060816/#sec-attribute-types
[3]   http://www.w3.org/TR/2005/REC-xml-id-20050909
[4]   http://www.w3.org/TR/1999/REC-xslt-19991116
[5]   http://www.w3.org/TR/1999/REC-xpath-19991116

Is the plan to render (nearly) everything as elements rather than attributes?  
GLUE has many items have "required" (1) or "optional" (0..1) cardinality and 
contain no further markup, so I feel they would, for the most part, be better 
rendered as an XML attributes.

Is the proposed GLUE/XML intended to be used by services when they publish 
information about themselves for site-level aggregate?  If so, the current 
proposal (the rule that One-to-Many relationships are represented as 
parent-child) looks as if a Service must know site-level information (such as 
AdminDomain).  This is undesirable for data normalisation.

As an alternative, suppose One-to-Many relationships be represented as either 
an XML element hierarchy or (for top-level elements, only) as an attribute 
("parent", say) that has type URI and contains the URI of the containing 
element's ID.  A service could publish its information and only have to know 
the parent element's URI.

Finally (just as a general comment) my impression is that there is too great 
an emphasis on XML Schema; because of this, the GLUE/XML rendering appears 
hampered by limitations of XSD and the rules are designed as if the XML is to 
fit what XSD supports (e.g., the "extensible enumerations" section).  If so, 
I feel this is "putting the cart before the horse": I feel the XML should 
convey precise and compact representation of the schema, whilst being easy to 
parse and comprehend.  "Hacks" to support extensibility in the XSD, like 
<State> vs <RunningState>, obfuscate the XML in favour of XML passing XSD 
validation checks.

(I'm in favour of providing a validation mechanism, but does the validation 
needs to be strong?  If it's a choice between having a simple XML design that 
can only be validated weakly via XSD or a complex XML that can be strongly 
validated, I'd perfer the former.)

Cheers,

Paul.