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/GLUE2XMLSchem... 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.